Andy Wingo <wi...@pobox.com> writes:
> On Tue 13 Dec 2011 16:27, David Kastrup <d...@gnu.org> 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?
It would appear that program-bindings on an anonymous lambda function
that just creates a list of all # and $ scraps in #{ ... #} would
deliver that. Then one needs to correlate every structure recursively
with the resulting list of bindings, and create an anonymous lambda
whenever the intersection is non-empty.
It's doable, but its likely easier to just don't bother sorting out the
non-environment depending functions from those that do. I should hope
that storing and referencing near-trivial lambda functions should not be
all too expensive in Guile v2.
So without something approaching the comparative seamlessness of the
procedure-environment/local-eval pairing, it is not likely that the
effort would be warranted. The code currently in Lilypond is working
well enough: as I said, I can work with any size of crowbar. And there
would be little point to exchange the current hack for a differently
tailored and likely more complex hack that is not a part of Guile proper
and thus has an even smaller expected live span than the current
solution.
--
David Kastrup
