Re: eval

From:

Neil Jerram

Subject:

Re: eval

Date:

12 Feb 2001 19:25:38 +0000

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