[Top][All Lists]
[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:24:41 +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?
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
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, (continued)
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Andy Wingo, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Mark H Weaver, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, David Kastrup, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Noah Lavine, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Mark H Weaver, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, David Kastrup, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, David Kastrup, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Andy Wingo, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?,
David Kastrup <=
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, David Kastrup, 2011/12/13
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, David Kastrup, 2011/12/13
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Ludovic Courtès, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, David Kastrup, 2011/12/14
- Re: Anything better for delayed lexical evaluation than (lambda () ...)?, Ludovic Courtès, 2011/12/14