Re: eval

[Marius Vollmer]

Neil Jerram <address@hidden> writes:

> `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.

Yes, thanks, this was very helpful.

> 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. ???

The best answer I have so far is "I don't really know for sure, yet,
but I like it that way."

I did not want to make such a bold move as you outline in the rest of
your mail, so I didn't think about how to get rid of current-module
altogether, as far as the interface between the evaluator and the
current module is concerned.

I think we could make that move, technically.  A possible
implementation of `export' could be, modulo eval-when stuff:

    (define-macro (export . syms)
      `(module-export! (evaluation-module) ',syms))

where `evaluation-module' works as you describe it.  It will climb up
the lexical environment until it finds the top-level and will extract
the module from it.  This is not currently possible, because we have a
closure in the top-level frame, but we can devise something that will
allow the `environment->module' operation.

It is very important that (evaluation-module) is contained in the
generated code, and it must be a special form, otherwise it will pick
up the wrong environment.


On the other hand, I don't know if this isn't more magical than the
current-module concept that we have right now.

I'd say that every useful use of eval will be in something that
resembles a repl.  You will probably allow the user to evaluate a
sequence of expressions, including module system operations.  In that
case, you need the concept of a current module anyway, and you want
`define-module' et al to interact with that in the right way.  We
could define `define-module' to change the top-level frame of the
evaluation environment, but how do we communicate this back to the
custom repl so that it can invoke `eval' with the right environment
next time?  We can have a hook that `define-module' calls, etc, but is
that simpler than what we have now?

All in all, when writing a repl, I'd say I prefer explicit use of
`set-current-module', `current-module', and `primitive-eval' over
`eval'.  In my view, `eval' is not a good fit for a module system that
allows the user to switch the current module interactively.

We could indeed solve this problem by disallowing the user to switch
modules from regular expressions, and provide meta-commands for this
that would not go thru `eval'.  But then we need to find a way to
integrate the module system with `load' or with whatever actually
loads Scheme code.  I'm sure we could do that, but I (personally)
don't think it would be an improvement over the current arrangement.

The current practice is, in my view, simple and powerful.  It allows
the clean building of high-level module system functionality, without
the need to change fundamental aspects of the repl (like introducing
meta commands) or the loader (like specially recognizing
`define-module' as the first form).

The current practice is also not difficult to understand, I think.  It
is just that the interface of R5RS `eval' is slightly wrong for our
purposes.  In my view, `eval' is for people who do not want to deal
with the module system (because they want to write portable code, for
example), and for that use, it is important that `eval' saves and
restores the current module.  People who do want to deal with the
module system should use `primitive-eval'.

> Does this make any sense?

Yes, it makes a lot of sense.  I'm just not sure if I follow you in
that it would be advantageous.  However, I'm trying not to be dogmatic
here, of course...