Re: eval

[Dirk Herrmann]

On 9 Feb 2001, Neil Jerram wrote:

> (eval/no-module-restore '(define-module (app one)) '(app two))
> 
> Either the expression has no effect, or it means that next time we do
> `(define-module (app two))', we will actually, automatically, be in
> module (app one), which would be silly.  Do you see what I mean now?

Sorry for being dense, but I don't get it.  Maybe the confusion comes from
the fact that I have added an <env> parameter to eval/no-module-restore,
which is not necessary:  Does the example make more sense to you if we
read it that way:

  (eval/no-module-restore '(define-module (app one)))

If so, then I don't see the big difference:  With the <env> parameter
added (which was just done as an example - I actually like the version
without <env> parameter better, and that's the way that Marius will
implement 'primitive-eval') it is just an additional switch to the given
environment at the beginning of the evaluation, nothing more.

> So, on the one hand, generalizing `(eval-in-current-module exp)' to
> `(eval/no-module-restore exp env)' doesn't make sense.  And on the
> other, I (like you, I believe) don't like the implicit use of
> `the-module'.

It's a matter of interpretation:  primitive-eval does not 'implicitly use'
the-module:  It does not care about it.  From the point of view of
primitive-eval, the-module is just a global variable as any other one.  If
it gets changed, it gets changed.  If not, then it stays the same.

> - As far as I can tell, my approach will also make the current module
>   system work consistently and reliably, and is not dramatically
>   harder to implement.  On the other hand, my knowledge of the module
>   system is not very deep, so there could be ramifications that I've
>   missed.

The major point is, that it will break a lot of code.  We will break a lot
of code anyway if the new module system will be introduced, but we want to
try to break code only _once_.  This means, as long as we don't install
the new module system, we can fix problems with the old system.  But we
should not perform big incompatible changes that may be changed again.  

> - There is a demand for REPL meta-commands _now_.  IMO `define-module'
>   in the REPL context is broken (even after the fix that we are
>   discussing) as it confuses definition of a new module with switching
>   to an existing one.  (Analogy with `define' cannot be assumed to be
>   valid just because the name contains "define"!)  Keisuke has done or
>   is already doing work to support REPL meta-commands.

I consider meta commands as a potential solution to avoid a couple of
problems, but currently I am not even sure which kind of problems we
actually want to avoid.

> - I have a strong suspicion that we will only arrive at the new module
>   system by incrementally improving the existing one.

I am also a friend of incremental improvements.  However, with changes
that break a lot of code, I would rather be convinced that it is the right
thing.  I have not yet thought enough about the different wishlist items
and the requirements that we have for the new system.  I am planning to
take the wishlist document, take a look at each of the points and write
down some comments and questions.

Best regards,
Dirk Herrmann