Re: eval

[Neil Jerram]

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