[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: eval
From: |
Neil Jerram |
Subject: |
Re: eval |
Date: |
13 Feb 2001 23:17:43 +0000 |
>>>>> "Marius" == Marius Vollmer <address@hidden> writes:
Marius> Neil Jerram <address@hidden> writes:
>> 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.
Marius> This is what is happening, now that we have synced the
Marius> module returned by `current-module' and what the evaluator
Marius> is actually using when evaluating top-level code. For
Marius> non-toplevel code, `export' is now illegal.
Yes - nice patch! The code for `define-public' is much cleaner now.
The `begin' change is nice too: I had been wondering how it could be
done without returning to the REPL between each subform.
>> 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'.
Marius> The problems are not with `define-public' which only
Marius> refers to the current module, they are with
Marius> `define-module' which is changing what module is
Marius> designated as the current module.
`define-module' is the immediate problem, but I still think that the
problem stems from `define-public'/`export'. I will try to explain
what I mean by the following sequence of questions.
Q. Why does "(eval '(define-module (guile-user)) (current-module))"
(the expression that used to be used by the REPL) not succeed in
switching (current-module)?
A. Because `eval' saves, modifies and restores the value of
(current-module) around the evaluation of the expression that it is
given.
Q. Why does `eval' save, modify and restore the value of
(current-module)?
A. So that "(eval <expression> <some-module>)" works where
<expression> somehow involves reference to (current-module) [and
<some-module> is not the same as the external value of
(current-module)]. The most important examples of such <expression>s
are `export' and `define-public'.
Q. But why does the concept of (current-module) need to be set up and
later restored when the information that `export', `define-public'
etc. need is already available in the `eval' expression's environment
parameter?
A. ???
It seems to me that it would be simpler if <the module corresponding
to the top level evaluation environment> was automatically derived
from the environment parameter. `(current-module)' would still have a
use, but only as a REPL concept, used to track the REPL's idea of the
currently selected module.
Suppose that it is possible, given a top level environment, to deduce
the module whose top level environment it is; in other words the
inverse of `scm_top_level_env (SCM_MODULE_EVAL_CLOSURE (module))'.
Assuming this is possible, let's call it `environment->module'.
If we then define (evaluation-module) as `(environment->module
(the-environment))', and change `define-public' and `export' (etc.) to
refer to `(evaluation-module)' rather than `(current-module)',
expressions like "(eval <expression> <some-module>)", where
<expression> uses (evaluation-module), would work automatically
_without_ `eval' needing to modify and restore anything.
(I'm not sure about the details of `(the-environment)' here: a quick
experiment shows that it captures the local environment, not the top
level, so this might only work if all the relevant macros were defined
directly using procedure->syntax or procedure->memoizing-macro, rather
than just using (evaluation-module) in their definitions.)
Finally, because `eval' would not save and restore anything, changes
to (current-module) made by `define-module' would leak automatically
even when using `eval', and so we would have no requirement for
`primitive-eval'.
Does this make any sense?
Best regards,
Neil
- Re: eval, (continued)
- 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, 2001/02/12
- Re: eval, Marius Vollmer, 2001/02/12
- Re: eval,
Neil Jerram <=
- 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