[R6RS] eval

[dyb at cs.indiana.edu]

> action items from 6/6/2006
>   - mail library->environment proposal (Kent)

Here it is, with the name "environment" instead of "library->environment".

Kent

--------

As in Mike's proposal, I propose keeping eval essentially as it is in
R5RS, i.e., keep: 

  (eval x env)

  which evaluates x (which must be an s-expression representing a valid
  expression) in env.

In place of Mike's eval-libraries <impexp-form>, I propose that we add a
new <import-phase> instead:

  <import-phase> -> expand | run | eval

In place of Mike's library-environment procedure, I propose:

  (environment <import-spec>*) ; syntax

  which evaluates to an environment containing the specified imported
  bindings, with the following restriction on <import-spec>*: If the
  (environment <import-spec>*) form appears within the body of library L,
  the set of bindings specified by <import-spec>* may include only
  bindings that are imported "for eval" in L's header.  Similarly, if an
  (environment <import-spec>*) form appears within an expression x passed
  to eval along with environment env, the set of bindings specified by
  <import-spec>* may include only bindings that are in env.

Rationale:

  While library-environment creates an environment from all and only the
  exports of a single library, the environment form allows the set of
  bindings to be drawn from multiple libraries with all of the subsetting
  and renaming features available in a library header.

  While the eval-libraries form identifies the set of whole libraries
  that are available for eval, the current proposal leverages the
  library-header <import-spec> syntax to allow the programmer to identify
  subsets of those libraries to make available.

  We could combine eval and environment into a single eval syntactic
  form (eval expr <import-spec>*) without any loss of generality, but by
  keeping the two separate, we maintain a certain level of backward
  compatiblity.  In particular, we can support scheme-report-environment
  and null-environment in our R5RS compatibility library.

Finally, I suggest that we not add eval-library.  I originally believed
that eval-library was necessary to create custom libraries for eval, but
we can do that more cleanly with (environment <import-spec>*).  While
eval-library may have other uses, I fear that most of those uses are to
circumvent the absense of a top-level environment.  In particular, it may
be possible to create a top-level environment using the module namespace,
an abuse I suspect none of us wants to condone.  If we want a top-level
environment, we should add one.

Furthermore, I've been puzzling over a clean way to limit the exports of a
constructed library form statically and a clean way to reconcile
dynamically created libraries with the static declaration of eval
libraries (via eval-libraries in Mike's proposal or the eval import-phase
in my proposal) and have not come up with anything.  Essentially, I think
this gets us too deep into language design and is better left for the SRFI
process and perhaps R7RS or beyond.
 
Notes:

We could eliminate <import-phase> eval and say instead that 'the set of
bindings specified by <import-spec>* may include only bindings that are
imported "for *run*" in L's header'.  This is simpler for the user but
would require an implementation to scan the code for environment forms to
know for which "imported for run-time" bindings compile-time as well as
run-time information must be available at run time.  I suspect that this
isn't much of a burden for implementations that actually maintain separate
compile- and run-time information.

I'm unsure about phase-separation issues wrt eval.  Should we have one
invocation of a library for both run and eval (if eval is different from
run)?  Do we need a separate eval-expand import phase to separate the
expand- and run-time phases of an expression passed to eval?  Or if eval
is the same as run, should eval-expand also be the same as expand?  If a
transformer calls eval, do we need expand-eval and expand-eval-expand? 
(Similar phase-separation issues arise with Mike's eval-libraries
declaration, so we can't get out of this simply by adopting
eval-libraries.) Matthew?

If we decide to allow local imports, thus requiring that an implementation
expand a library in order to determine its imports, we should also
consider eliminating the environment-form restriction, since it is no more
trouble to scan for environment forms than to scan for import forms.