Eli Barzilay  <eli@barzilay.org> 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)
		(y 3))
	    (eval '(+ x y 4) (the-environment)))
	9
	>

But I suspect that in general it would be hard to get compiled code
to work correctly with that (for some values of "correctly").


-Rob

p.s. Of course, (eval '(let ((x 1)) x)) should always work...

-----
Rob Warnock, 31-2-510		<rpw3@sgi.com>
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: aaanalyst@sgi.com and zedwatch@sgi.com aren't for humans ]