Re: eval

[Dirk Herrmann]

On 1 Feb 2001, Neil Jerram wrote:

> >>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:
> 
>     Dirk> Hello list-eners :-) PROBLEM: --------
> 
>     Dirk> Some time ago, the behaviour of eval in CVS was changed.
>     Dirk> The effect of that changes was, that after evaluating the
>     Dirk> given code, the environment that was active before (eval
>     Dirk> ...) is restored.  In other words, code like (eval
>     Dirk> '(define-module (foo)) <environment>) will not influence the
>     Dirk> (current-environment) after the evaluation is finished.
> 
> In order that I can be sure that I understand the problem, please
> could you remind me about the situations in which we want evaluation
> of `(define-module (foo))' _not_ to change (current-environment) after
> the evaluation.

We don't want that calls to scm_eval or 'eval change
(current-environment), but that evaluations of code within a file change
the current environment for the rest of the file, but not beyond that.

Example:

---- file starts here ----
(define-module (foo))

<further code>
----- file ends here -----

Here, we obviously want <further code> to be executed within (foo).  As
the loader reads '(define-module (foo))', evaluates it, and then reads and
evaluates <further code>, there must be a way to communicate a change of
the current environment between the different expressions read from the
file.

However, 

  (let* ((m (current-module)))
        ((x (eval '(define-module (foo)) <some env>))))
    <further code>)

shouldn't.  Maybe a different example can make things clearer:

  (define-module (foo))
  (eval '(+ 1 2) (resolve-module (bar)))
  (display (current-module))

We would clearly say that the display command should display module (foo),
not module (bar).  However, the expression (+ 1 2) should be executed in
an environment, where (bar) is the current module.  Thus, eval can not
be implemented to take over the current module to the outer code.

Best regards,
Dirk Herrmann