[R6RS] eval

Michael Sperber sperber at informatik.uni-tuebingen.de
Thu Jun 22 13:39:04 EDT 2006


dyb at cs.indiana.edu writes:

>> - I'd like to keep `eval-libraries' as an <impexp-form>, and turn
>>   `environment' back into a procedure that accepts an arbitrary number
>>   of arguments, each being an S-expression representing an
>>   <import-spec>.
>>
>>   This makes the set of libraries available to `eval' a bit more
>>   static than in your proposal (no macro-expansion), but the actual
>>   <import-specs> more dynamic (run time rather than expansion time).
>
> The set of libraries is just as static either way.  I think I must
> not have made myself clear before.

I think that's my fault.

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

> If environment is a procedure, the set of valid <import-spec>s that can
> appear within it would have to be determined dynamically.  What would the
> set be?  If I understood your original proposal, the set would still be
> determined statically by some strange tie between the particular binding
> for environment (nee library-environment) imported into a library and
> the "eval libraries" listed in the header of that library. This strange
> tie is what I was trying to avoid by making environment a sytactic form.

Your understanding is correct.

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

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



More information about the R6RS mailing list