[R6RS] eval

[dyb at cs.indiana.edu]

> I would prefer a variant with the following modifications relative to
> your proposal:
>
> - I'd prefer if the eval and run phases were the same.  As the imports
>   themselves are determined statically, this allows `eval' to the same
>   module state as the running code.  Separating them and thus having
>   `eval' potentially instantiating modules all over the place, would I
>   conjecture, be quite surprising to most users.

That seems reasonable to me.  I assume you mean libraries. ;-)

> - I'd like to keep `eval-libraries' as an <impexp-form>, and turn
>   `environment' back into a procedure that accepts an arbitrary number
>   of arguments, each being an S-expression representing an
>   <import-spec>.
>
>   This makes the set of libraries available to `eval' a bit more
>   static than in your proposal (no macro-expansion), but the actual
>   <import-specs> more dynamic (run time rather than expansion time).

The set of libraries is just as static either way.  I think I must not
have made myself clear before.  With your proposal one would write, I
believe,

  (eval-libraries lib)

as an (unexpanded) impexp form, while with my proposal one would write

  (import (for lib eval))

also as an (unexpanded) impexp form.  One would likely include both eval
and run phases in many cases:

  (import (for lib run eval))

and one might also want to restrict the set of imports via subsetting:

  (import (for (only lib frob widget) run eval))

If an identifier binding isn't imported from a library "for run" by an
import form at the head of a library, then an environment form in the
library cannot access that binding.

If environment is a procedure, the set of valid <import-spec>s that can
appear within it would have to be determined dynamically.  What would the
set be?  If I understood your original proposal, the set would still be
determined statically by some strange tie between the particular binding
for environment (nee library-environment) imported into a library and
the "eval libraries" listed in the header of that library. This strange
tie is what I was trying to avoid by making environment a sytactic form.

Incidentally, we might consider a simpler (the-library-environment) form
instead of (environment libspec ...).  (the-library-environment) would
return a library containing the set of bindings imported "for eval" in the
enclosing library.  The environment form is more general, of course, in
that it allows one to construct subsets of the library that would be
returned by (the-library-environment), possibly with different renamings
or aliases.  I would be happy with either form.

Kent