sperber at informatik.uni-tuebingen.de
Sun May 7 11:03:14 EDT 2006
Here's a proposal revised further as a basis for further discussion;
the main changes is that I changed `eval-library' to ignore the name
specified in the library expression to avoid unavoidable problems.
- 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', `interaction-environment', and
`scheme-report-environment'. (We might re-introduce
some of them in an R5RS-compatibility library.)
- 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 for future calls of
This returns a library-environment specifier for the library
definition. The name of the defined library is ignored.
- 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