[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