[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
- Re: eval, (continued)
- Re: eval, Dirk Herrmann, 2001/02/07
- Re: eval, Neil Jerram, 2001/02/07
- Re: eval, Dirk Herrmann, 2001/02/09
- Re: eval, Neil Jerram, 2001/02/09
- Re: eval, Marius Vollmer, 2001/02/09
- Re: eval, Neil Jerram, 2001/02/10
- Re: eval, Dirk Herrmann, 2001/02/09
- Re: eval, Marius Vollmer, 2001/02/10
- Re: eval, Neil Jerram, 2001/02/10
- Re: eval, Dirk Herrmann, 2001/02/11
- Re: eval,
Neil Jerram <=
- Re: eval, Marius Vollmer, 2001/02/12
- Re: eval, Neil Jerram, 2001/02/13
- Re: eval, Marius Vollmer, 2001/02/13
- Re: eval, Michael Livshin, 2001/02/14
- Re: eval, Neil Jerram, 2001/02/14
- Re: eval, Marius Vollmer, 2001/02/09
- Re: eval, Marius Vollmer, 2001/02/08
Re: eval, Neil Jerram, 2001/02/05