Re: eval

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:

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

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

    Dirk> will switch to (some thing).  Why is this meaningless?

What I mean is that the meaning of _general_ expressions like this is
very confused.  Take a concrete example (please ignore the missing
`resolve-module'):

(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?

The only specific use which makes sense is the one which Marius
proposed, where the ENV parameter is implicit and tightly coupled to
the same object that gets updated by `define-module' - i.e. the
`the-module' fluid.

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'.

    >> 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'.

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

That is an important distinction, I agree.  However...

- 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.

- 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 have a strong suspicion that we will only arrive at the new module
  system by incrementally improving the existing one.

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

I agree that the wishlist is an extremely useful document, and that
some of the points in it are not clearly defined.  It would be good to
clarify those points.  In the meantime, and with proper consideration
of the uncertainties that arise from those points being unclear, we
can use the wishlist equally well to evaluate proposed incremental
improvements, as to evaluate a complete new design.

Best regards,
        Neil