Eli Barzilay <email@example.com> wrote:
| > The problem comes with the various evaluation environments..
| > In a perfect world, 'load' would accept an evaluation environment as
| > well, which would solve the problem trivially..
| That's not a `load' problem, it's an `eval' problem and I think it was
| discussed not too long ago why something like (let ((x 1)) (eval 'x))
| is not expected to work.
Mainly because "eval" is a procedure, not a macro, and procedures
don't get the lexical environments of their callers. Even this is
not expected to work:
(let ((x 1))
(eval 'x (interaction-environment)))
since the "interaction-environment" is intended (says R5RS, by my reading)
to be the same as the top-level user REPL.
Now in some implementation it *might* be possible to make this work
(for some values of "work"):
(let ((x 1))
(eval 'x (current-lexical-environment)))
where "current-lexical-environment" is a macro and/or system-defined
syntax to capture & reify a lexical environment. For example, Elk 3.0,
a pure interpreter [with shallow binding, not that that matters here],
contains a magic primitive "the-environment" (note: *not* a closure,
since that would contain its own frozen environment):
> (let ((x 2)
(eval '(+ x y 4) (the-environment)))
But I suspect that in general it would be hard to get compiled code
to work correctly with that (for some values of "correctly").
p.s. Of course, (eval '(let ((x 1)) x)) should always work...
Rob Warnock, 31-2-510 <firstname.lastname@example.org>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: email@example.com and firstname.lastname@example.org aren't for humans ]