[R6RS] eval

[dyb at cs.indiana.edu]

> > With your proposal one would write, I believe,
> >
> >   (eval-libraries lib)
> >
> > as an (unexpanded) impexp form, while with my proposal one would write
> >
> >   (import (for lib eval))
>
> Except that, in my world, you would have to put the `eval-libraries'
> form into the surrounding `library' form.

You would have to do so in my world too.

> If you don't have that, you
> can't use the library with `eval.'  I didn't really make clear that
> using `eval-libraries' really only makes sense in the `library' form,
> not for the `environment' procedure.

Again, this is the same with my proposal.  The only difference is that one
would use the syntax (import (for lib eval)) in my proposal where one
would use the syntax (eval-libraries lib) in yours.  In both cases, the
syntax would appear in the enclosing library header.  Thus, it's almost
just different syntactic sugar, except that mine is syntactically more
consistent with what we already have with "for expand" and "for run" and
it also allows one to limit the set of bindings available from an imported
library for use by eval.

> > Incidentally, we might consider a simpler (the-library-environment) form
> > instead of (environment libspec ...).  (the-library-environment) would
> > return a library containing the set of bindings imported "for eval" in the
> > enclosing library.  The environment form is more general, of course, in
> > that it allows one to construct subsets of the library that would be
> > returned by (the-library-environment), possibly with different renamings
> > or aliases.  I would be happy with either form.
>
> That's also fine with me.  But (playing devil's advocate) aren't you
> creating a tie between `the-library-environment' and the surrounding
> library that's just as strange as the one I proposed?

No, because the-library-environment is a syntactic form in my proposal and
can query for the information it needs at expand time.  The expander knows
which library it's currently expanding, so it's easy to deliver this
information.  On the other hand, a procedure, e.g., your
library-environment, that isn't invoked until run time has to query for
the information at run time.  There's no way for it to get the right
information without identifying the library it was imported into, which
means that the library-environment binding has to be handled as a special
case by the library system.

Incidentally, I've decided I prefer the-library-environment to environment.
It's simpler, it's exactly what one wants in most casss, and we don't have
to deal with questions about the names of bindings when the import "for
run" at the head of a library does some renaming but the <import-spec>s in
an enclosed environment form doesn't.  If someone needs to create
different environments, they can define and import from multiple libraries
with different "for eval" imports and have the libraries export a
procedure that returns the value of (the-library-environment) in that
library, e.g.:

  (library "r6rs-full"
    (import (for r6rs run eval))
    (export r6rs-full-enviornment)
    (define (r6rs-full-environment) (the-library-environment)))

  (library "r6rs-no-oof"
    (import r6rs (for (except r6rs open-output-file) eval))
    (export no-oof-enviornment)
    (define (no-oof-environment) (the-library-environment)))

Kent