Re: eval

[Dirk Herrmann]

On 2 Feb 2001, Neil Jerram wrote:

> Comparing with your SOLUTION, I think this is the same but with
>   - current-module       instead of  the-interaction-module
>   - current-environment  instead of  the-module
>   - specification of what the-module is restored to by eval
>   - specification which variable is important to the evaluator.

It is similar, yes.

> Regarding your GENERALIZATION,
>   - I think eval will be broken if it relies on its calling code to
>     restore a sensible environment; e.g.:

Well, I seem to have expressed myself badly:  The environment will be
restored by eval.  However, the question whether the return value of
(interaction-environment) is changed is not part of 'eval any more.  To
get (interaction-environment) return a different value is the
responsibility of the caller of eval.  However, (current-module) will be
taken care of by 'eval.  Thus, with my suggestion as I intended it your
example

>     (begin
>       (eval '(lambda (x) x) (null-environment 5))
>       (list "done"))
>     =>
>     Unbound variable: list

would not give an error.  A better example would be:

  (begin
    (current-module)
    (interaction-environment)
    (eval '(define-module (foo)) <some environment>)
    (current-module)
    (interaction-environment))

Independent of whether my SOLUTION or my GENERALIZATION was used, both
calls to (current-module) would return the same module.  The difference
between the two is, that with my SOLUTION the second call to
(interaction-environment) would return (foo), while with my GENERALIZATION
the both calls to (interaction-environment) would return the same
module.  Making (interaction-environment) return (foo) could be achieved
by doing the following:

  (begin
    (current-module)
    (interaction-environment)
    (eval '(define-module (foo)) <some environment>)
    (set-interaction-environment the-module*)  ;; this line was added
    (current-module)
    (interaction-environment))

I. e. the control about when (interaction-environment) changes is in the
hand of the caller of eval.  However, the name the-module* is definitely
bad.


However, we should be aware of the fact, that all these solutions are
workarounds until we know how the module system will work.  Our problems
with eval are based on the definition of 'define-module'.  If such a thing
would not exist in the final module system, eval could work just cleanly,
that is setting and restoring the current environment.

Best regards,
Dirk Herrmann