[R6RS] eval

[Michael Sperber]

Here are my suggestions for eval:

- Keep `eval' itself much like it is.

- Ditch `null-environment'.

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

Issues:

- Do we want to offer a library corresponding mostly to R5RS?  (I'd
  say yes.)

- Do we want to omit `scheme-report-environment' altogether.  (I'd say
  no, keep, at least for 5 argument.)

- Do we want to specify (scheme-report-environment 6)?  (I'd say no.)

- Do we want to restrict the set of libraries available through
  `library-environment'?  My inclinication is to say that at least the
  library the reference to eval is in, and the libraries imported by
  it must be available, and more libraries can be made available
  through an implementation-specific mechanism.  (Which we'd strongly
  encourage implementors to provide.)  This way people can ship sets
  of libraries or applications containing calls to `eval' without
  having to include everything that's, say, in the development system.

- Do we want to crack down on programs that assign to library
  variables or contain top-level definitions?  My inclinination is to
  say that the behavior is unspecified.  We might restrict
  implementations to one of two choices: either run the code as if
  appended to the library body, or raise a specified exception, say
  &eval-assignment or &eval-definition.  I'd be in favor of that.


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