Andy Wingo <wi...@pobox.com> writes:
> On Tue 13 Dec 2011 17:08, David Kastrup <d...@gnu.org> 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
