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

[David Kastrup]

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?

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