Re: eval

[Dirk Herrmann]

On 7 Feb 2001, Neil Jerram wrote:

> In fact, of course, it is _very_ different.  The problem is the
> implicit reference to `the-module'.  Yet, if we follow Dirk's
> suggestion of making the reference explicit, as in
> `(eval/no-module-restore exp (current-module))', and `exp' is
> `(define-module (some thing))', we arrive back at the interpretation
> of a meaningless (IMO) expression.

Hmmm?  With the definition of eval/no-module-restore (or
primitive-eval) the expression

  (eval/no-module-restore '(define-module (some thing)) (current-module))

will switch to (some thing).  Why is this meaningless?  However, you are
right that

  (eval '(define-module (some thing)) (current-module))

does not have any effect, because the (current-module) will be restored
after eval is finished.

> Perhaps, after all, the Right Thing is not to try to support `(eval
> exp env)' where `exp' is an expression that would like to change the
> currently selected module so that the change lasts beyond the
> completion of the `eval'.

Maybe you are right.  However, these are suggestions which are valuable
for the design of the _new_ module system, while Marius' suggested fix
will make the current module system work more consistently and reliably.

For discussions about the new module system we should take the wishlist in 
  http://www.glug.org/docbits/modules.texi.txt
as a basis in order to find out what we actually expect from the new
module system:  Some of the points in that document are not stated clearly
yet (for example:  What is meant with separate compilation of
modules?) and some are contradicting each other (for example:  using the
file system as module repository <---> having multiple modules in one
file).

Best regards,
Dirk Herrmann