[R6RS] eval

[Michael Sperber]

Here's a revised version as a basis for further discussion:

- Keep `eval' itself much like it is, but tighten its spec to require
  an implementation to raise an exception if the evaluated expression
  contains a top-level definition or tries to assign to a
  library-top-level variable.

- Ditch `null-environment' and `scheme-report-environment'.  (We might
  re-introduce `scheme-report-environment' in an R5RS-compatibility
  library.)

- Add a procedure

  (library-environment library-specifier)

  where library-specifier is whatever the library proposal uses to
  identify a library (currently a string).

  This returns a specifier for an environment that contains all the
  bindings in the named library.  As with `scheme-report-environment',
  the effect of assigning a variable bound in a library environment is
  unspecified, as is the effect of evaluating non-expression programs.

  Probably, `scheme-report-environment' could be defined in terms of
  `library-environment' by making available libraries that correspond
  to whatever we want it to correspond to.

- Add a procedure 

  (eval-library library-expression)

  that takes an S-expression representing a library definition (which
  will presumably still exist, even after the changes to the library
  mechanism), and makes the library available in the running program.

  This returns a library-environment specifier.  The defined library
  must have a name disjoint from all others in the system, just like
  statically defined ones.

- Have `eval', `eval-library' and `library-environment' live in a
  special `eval' library.  Add to the library system:

  <impexp-form> -> (eval-libraries <lib-path>*)

  This only makes sense when `eval' is imported into the same
  library---it makes the specified libraries available for import in
  the `library-environment' and `eval-libraries' bindings so imported.
  It is an error to import any others.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla