Re: Anything better for delayed lexical evaluation than (lambda () ...)?

[Mark H Weaver]

David Kastrup <address@hidden> writes:
> Very funny.  If x is not an integer, it is put into the music argument
> instead, and the next "argument" is not an argument but independent
> code.

Ah, okay.  In that case, the design of the Lilypond language does indeed
make compilation (or even parsing) before execution absolutely
impossible.  Oh well.

>> You are using Guile in a very unusual way.  You have constructed a
>> hybrid language of both Scheme and Lilypond,
>
> That's what "extension language" as opposed to "implementation language"
> means.

I guess this is the crux of your misunderstanding over what Guile is
"supposed to be".  Apparently you believe that an "extension language"
is one that allows you to mix your own language interpreter with the
extension language's interpreter to build a hybrid language that is
implemented by both code bases working together.

Can you please find a reference to back up your definition of "extension
language"?  I looked and I couldn't find one that supports your view.
For the record, I don't believe that this use of Guile was _ever_ what
Guile was intended for.

Anyway, it's water under the bridge now.  To be fair, some past
maintainer of Guile apparently decided to make "procedure-environment"
part of the public API -- a very serious error in my view -- and the
Lilypond developers made use of this functionality to build their
system.  I guess the responsibility to make this right ultimately rests
on our shoulders, as inheritors of the unwise promises made by our
predecessors.

In order to make this right, and in general to support languages like
Lilypond that cannot even be parsed before execution, I guess we should
implement the "capture-lexical-environment" special form, along with a
"local-eval" that makes use of it.  I guess the most straightforward
implementation is to simply inhibit compilation of any top-level form
that contains a "capture-lexical-environment" special form.  Instead we
would use the bootstrap evaluator to execute such top-level forms, and
also to implement "local-eval".

Andy, this is your area.  I'd be willing to work on this, but before I
do, can you at least comment on whether you think this is the right
approach, and what complications I'm likely to run into along the way?

    Thanks,
      Mark