dyb at cs.indiana.edu
dyb at cs.indiana.edu
Tue Jun 13 01:01:53 EDT 2006
> action items from 6/6/2006
> - mail library->environment proposal (Kent)
Here it is, with the name "environment" instead of "library->environment".
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.
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.
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
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.
More information about the R6RS