[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: Anything better for delayed lexical evaluation than (lambda () ...)?
Date: Tue, 13 Dec 2011 17:54:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

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

> 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]