[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eval

From: Dirk Herrmann
Subject: Re: eval
Date: Mon, 5 Feb 2001 00:32:04 +0100 (MET)

On 4 Feb 2001, Marius Vollmer wrote:

> I find this and what has been discussed in the sequel needlessly
> complicated.  What is wrong with this:
>     Conceptually, we should probably isolate the current-module from
>     eval.  We should have `with-current-module' and
>     `eval-in-current-module' [I like long names], and `eval' would be
>         (define (eval exp env)
>           (with-current-module env
>             (eval-in-current-module exp)))

OK, if I understand your idea, the functions/macros would have the
following semantics:

* (eval-in-current-module exp) evaluates exp in whatever is the current
module, and whichever module happens to be the current module at the end
of the evaluation will be the current module for the environment _after_
the evaluation.  In other words, eval-in-current-module may potentially
change the top-level-environment for the code surrounding the call to

* (with-current-module env body) switches to the environment env and
evaluates the body in that environment.  After body is executed, the
original environment is restored.  (maybe this should be named
'with-module' ?)

Nice.  However, I think that we should still be aware of the underlying
problem:  With your approach it is possible to break the rule of
lexical scoping:

  (define foo 1)
  (eval-in-current-module exp some-module)
  (display foo)

Here, foo is not necessarily bound to the same location as is the
identifier foo in the first line.  If 'exp' changes the current
top-level-module, another definition of foo must be taken.  With the
current module system's API, we can't avoid to have such clauses, because
the define-module clause itself is sufficient to break lexical scoping.  
However, we should try to reduce the number of clauses to a minimum that
have this bad (IMO) sideeffect.

OK, so what is the difference to my approach?  With my approach, eval can
not be used to break lexical scoping.  (I agree, though, that it is
somewhat clumsy to modify some glocal variable as a sideeffect to eval.)

>     The only question that is left, as I see it, is whether to
>     overload the name `eval' with both a two-argument and a one
>     argument version, or we should have two distince names.  I can
>     live with either solution.
>     Because Dirk has expressed reservations about overloading one
>     name, I suggest to have two names:

I have thought about _why_ I have reservations about the overloading.  I
have found two reasons:

* Uses of a R5RS eval should be clearly distinguished from uses of a
different eval.  It should be easily possible, for example, to grep for
both uses, and it should be obvious to the eye at a first glance.
Different names would support this goal.

* If the environment specifier for eval was optional, then IMO most people
would expect this optionality to mean something like:  "If you omit the
environment specifier, then by default the current top level environment
will be used."  I think most people would be surprised if there were also
additional changes in the semantics, like how the expressions that are
evaluated can influence the surrounding code that called 'eval.

Best regards,
Dirk Herrmann

reply via email to

[Prev in Thread] Current Thread [Next in Thread]