David Kastrup <d...@gnu.org> writes:
> I am still fuzzy on what local-eval will do when the current module at
> the time of the-environment is different from that at the time of
> local-eval.
(the-environment) saves the module (where it is textually located) in
the lexical environment object. If (the-environment) was passed to
`eval', that's the module specified by `eval's second parameter. If
(the-environment) was passed to `primitive-eval', then that's the
(current-module) at the time primitive-eval was called.
`local-eval' passes the saved module to `eval', which temporarily
restores it (using dynamic-wind) as the current module during both macro
expansion and evaluation of the local expression. `local-compile'
passes the saved module as the #:env parameter to `compile', which has
the same effect as for `local-eval'.
> since the current module, even if nominally the same, can contain
> different variables at the time of local-eval, my take on that would be
> to not make it part of the environment at all. That is, everything that
> is not reachable through local scopes is not part of the environment.
I heartily disagree. A module is conceptually part of every lexical
environment evaluated within that module. That this makes sense is
particularly evident in the case of recursively defined top-level
procedures. For example, in
(define (factorial n)
(if (zero? n) 1 (* n (factorial (- n 1)))))
it would be crazy for any lexical variable "search path" starting from
within the definition of `factorial' to lead anywhere other than the
module where this definition was evaluated, i.e. where the top-level
`factorial' was bound.
Thanks,
Mark
