Mark H Weaver <m...@netris.org> 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
