Re: A plea for local-eval in 2.0.4

[Mark H Weaver]

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

I wrote:
> Actually, this is not true.  Within `local-eval', (current-module) is
> temporarily restored (using dynamic-wind) to the module saved in the
> lexical environment.
>
> This is probably not optimal.  [...]

Sorry, I was mistaken on this point, and most the rest of my email was
based on this false premise.

`local-eval' and `local-compile' temporarily restore (current-module)
during compilation, but _not_ during evaluation of the local expression.
Therefore, your statement above was indeed correct, and my
implementation actually does the right thing.

With this in mind, let me try again to respond this other question:

>>> so that (define x 5) inside of local-eval
>>
>> As Andy pointed out, I deliberately restrict the form passed to
>> `local-eval' (or `local-compile') to be an _expression_.  (define x 5)
>> is not an expression; it is a definition.  I explained the reason for
>> this restriction a few days ago[1] on this list.
>>
>>> 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.
>
> Well, use set! amd module-set! then for the example.

Indeed, (local-eval '(set! x 5) <env>) is _not_ equivalent to
(module-set! (current-module) 'x 5).

Assuming that `x' is not locally bound within the captured lexical
environment, the first sets `x' in the module captured by
(the-environment), i.e. the module where `x' would have been set if you
had put (set! x 5) in place of (the-environment).  The second sets `x'
in the (current-module) at the time of evaluation.

     Mark