sperber at informatik.uni-tuebingen.de
Wed Apr 19 15:15:37 EDT 2006
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
- Ditch `null-environment' and `scheme-report-environment'. (We might
re-introduce `scheme-report-environment' in an R5RS-compatibility
- Add a procedure
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
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
More information about the R6RS