guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark H Weaver
Subject: Re: Anything better for delayed lexical evaluation than (lambda () ...)?
Date: Tue, 13 Dec 2011 20:30:49 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Hi Noah,

Noah Lavine <address@hidden> writes:
> So I took a look at ice-9/eval.scm to see how difficult it would be to
> implement. Offhand, it doesn't look bad: the eval function there
> already passes around environment objects, so if it hit this special
> form, it would simply return its environment object (probably packaged
> up in a record so it would print nicely). Restarting it is also
> simple: call eval on an expression with the given environment. The
> environment objects already contain all of the information needed to
> evaluate expressions, so I don't think there is very much to do there.
>
> The part that seems more interesting to me is that Guile's evaluator
> attempts to memoize an entire expression before evaluating any of it,
> which I understand is impossible with Lilypond.

I also looked at eval.scm, and I see a complication.  The environments
passed around in ice-9/eval.scm do not contain any variable names.  The
evaluator works with memoized expressions, where variable references are
replaced by indices into the environment.

Therefore, the memoizer would need to be enhanced to support
(capture-lexical-environment) specially.  The evaluator may not know the
variable names, but the memoizer does.  After all, one of its jobs is to
convert variable references from symbols to indices.

The most straightforward solution I see is the following: When the
memoizer converts (capture-lexical-environment) into a memoized object,
it should embed within that object its own "memoizer environment" (a
list of variable names).

Then, when the (capture-lexical-environment) is evaluated, it simply
bundles together both the memoizer's environment (a list of variable
names) and the evaluator's environment (a list of variable values) into
an opaque lexical environment object.

When "local-eval" is called, it will need to first call the memoizer and
then the evaluator.  It will have everything it needs to do this within
the lexical environment object.

What do you think?

      Best,
       Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]