Re: A plea for local-eval in 2.0.4

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> Probably the easiest way to think about it is that (the-environment)
> acts like (list (lambda () <expr>) ...), with one `lambda' for each
> expression that you will later pass to `local-eval'.  Calling
> `local-eval' simply calls the appropriate procedure in that list.

Well, I experimented around a bit with lambda.  How does this work in
practice?  In Guilev1, the module is probably recorded as part of the
procedure-environment.  In Guilev2, a variable reference is compiled?
How does that work when there is no such variable?  It gets created with
an undefined binding?

> Calling the procedure created by a lambda expression evaluates the
> lambda body within the _lexical_ environment of the lambda expression,
> but within the _dynamic_ environment of the procedure call.  Top-level
> variables are part of the _lexical_ environment.  That means that
> top-level variable references within a procedure are looked up in the
> module where the procedure was defined, _not_ the (current-module) at
> the time of the procedure call.

Ok, here is the clincher and probably what I have actually confused this
with (it is a thin line): within local-eval, what is the return value of
calling (current-module)?  I would expect that it is the same as outside
of local-eval so that (define x 5) inside of local-eval would _not_ be
equivalent to (module-define! (current-module) 'x 5) as the first one
would take the current module at the-environment time, and the second
one would take it at local-eval time.

Correct?

-- 
David Kastrup