guile-devel
[Top][All Lists]
Advanced

[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:08:04 +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 16:27, David Kastrup <address@hidden> writes:
>
>>> It sounds like `current-bindings' is the thing you need.
>>
>> It will at least be a year before any solution that does not work with
>> Guile 1.8 will be accepted into Lilypond.
>
> It is possible to have similar interfaces with different
> implementations, using `cond-expand'.  lily.scm does this in one case,
> implementing 2.0 interfaces on 1.8.
>
> I'll take a look at implementing something like this.
>
> To summarize your issue: you have code like:
>
>   (lambda (a b c)
>     #{ here I have custom code that references lexical variables;
>        should it be able to set them too?  }#) 
>
> It would be relatively easy to pass in an alist of the lexicals, for
> reference purposes; but do you want to be able to set them too, from
> within that EDSL?

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)) #})

while something like

(let ((xxx 2))
  #{ xxx = "xx" #})

is not at the current point of time expected to work.  In fact, LilyPond
itself never accesses the lexical environment (or its simulation): the
environment is only made available to embedded Scheme.  It is basically
a black box, Scheme to Scheme.  Lilypond only uses the current module
for reading and writing variables.

-- 
David Kastrup




reply via email to

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