Re: eval

[Neil Jerram]

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

    >> What other breakages are there to consider?

    Dirk> All those (define-module (my-module)) lines that are spread
    Dirk> throughout the different .scm files.  For example,
    Dirk> guile-core/guile-readline/readline.scm begins with:

    Dirk>   (define-module (ice-9 readline) :use-module (ice-9
    Dirk> session) :use-module (ice-9 regex) :no-backtrace)

    Dirk> The point is, that 'load' also performs a read/eval loop and
    Dirk> has to switch to a different module with every call to
    Dirk> define-module.

FWIW, my approach addresses this.  Module files containing a
`define-module' form can only be correctly loaded using `use-modules'
or a `:use-module' option on another `define-module'.  So the module
switch can be performed by the code that implements `use-modules' or
`:use-module' rather than by `define-module' itself.

    Dirk> Alternatively, it is always possible to do

    Dirk>   (eval '(define foo ...) (resolve-module <name>)) (eval
    Dirk> '(define bar ...) (resolve-module <name>))

    Dirk> This means, that there is no _current_ module for normal
    Dirk> code.  However, the repl would still be able to use a
    Dirk> current module, but this would have no influence on the rest
    Dirk> of the system.  If the system was designed this way, we
    Dirk> could (instead of 'current-module') use
    Dirk> 'interactive-environment for the repl, which is what I
    Dirk> assume to be the intention of R5RS.

Yes yes yes!  I believe this is really the right way to go.  Since I
finally understood what Marius has been saying, and also your
explanations to Matthias Koeppe, I believe the fundamental problem is
the behaviour of `define' and `define-public'.

As far as I understand R5RS, `define' should always create a binding
in the environment in which the `define' expression is evaluated.  It
has nothing to do with modules at all.  Then, IMO, `define-public'
should be the same as `define' plus adding the new binding to the set
of bindings exported from that environment.

If `define-public' wasn't mixed up with scm_current_module, there
would be no need to restore scm_current_module after an `eval', so
`eval' could be implemented as what we are now calling
`primitive-eval'.  (And meta commands are a complete red herring, even
if they are convenient to type.)

But this is quite different from what currently happens, so it's a big
compatibility issue, and probably in the category of a change that we
can't justify twice.  So we really do need to sort out the new module
system!

Best regards,
        Neil