Andy Wingo <[email protected]> writes:
> On Tue 13 Dec 2011 16:27, David Kastrup <[email protected]> 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
