Re: A plea for local-eval in 2.0.4

[Mark H Weaver]

David Kastrup <address@hidden> 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