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

[David Kastrup]

Andy Wingo <address@hidden> writes:

> On Tue 13 Dec 2011 17:08, David Kastrup <address@hidden> writes:
>
>> The current implementation wraps scraps of code into (lambda () ...) and
>> executes them on-demand.  So the expectation is that embedded Scheme
>> code can have side-effects on the lexical environment like with
>>
>> (let ((xxx 2))
>>   #{ #(set! xxx (1+ xxx)) #})
>
> This closure strategy sounds fine, no?  It's what I would do, I think,
> if I understand the problem correctly.
>
> I thought that you were saying that lilypond code could reference and
> set Scheme lexical variables.

This thread started because I was thinking about creating Lilypond
structures that could be defined via procedures with setters.  In that
case, doing the equivalent of

(set! (lambda () (vref x 4)) 3)

would not work out all that well.  But that would likely be utopical
anyway.

> I was also under the impression that lilypond code could define
> lexical variables.

How would it do that without an API?

> If neither of these are true, then closures sound like a fine solution
> to me.
>
> Am I missing something?

Performance, space, simplicity, robustness.  Compiling five closures
that do nothing except accessing a single variable each is a bit
wasteful.

We keep having bug reports about bad stuff happening with #xxx and $xxx
constructs in Lilypond _comments_ inside of embedded Lilypond: since the
preliminary wrapping of $x and #x into lambdas does not recognize the
lexical structure of the embedded Lilypond passage, and one can't let
the lexer run in advance since the lexer is mode-dependent and thus
needs the parser to run in sync.

I am not saying that the current solution is unworkable.  But it does
nothing to recommend Guile in particular, while the solution using
procedure-environment did.  Even though taking the procedure-environment
of an arbitrary lambda function was quite more hackish (and less likely
to survive an optimizing compiler) than a special form for capturing the
current environment would have been.

But it was more like a master key than a crowbar.

-- 
David Kastrup