[R6RS] Eval vs. phases
sperber at informatik.uni-tuebingen.de
Tue Aug 1 01:30:54 EDT 2006
dyb at cs.indiana.edu writes:
> What you propose doesn't directly address the former, but I believe that
> this can be fixed with an extension of <import-phase>, which perhaps you
> are assuming.
Yes, I was.
> I had earlier suggested:
> <import-phase> = run | expand | (meta n)
> What you propose does address the latter, but not sufficiently. One
> problem is that transformers can also call eval, and I don't think your
> syntax reflects that possibility.
I guess I was assuming that the embedded (the-library-environment)
refer to the same environment as the the one passed to the outer
`eval'. Alternatively, `for-eval' could be annotated with a nesting
level the same way as the regular import.
> I've concluded from this that eval import specifications generally must be
> constructed dynamically, with Model 2, to parallel the structure of the
> evaluated form.
I disagree. Of course, fixing this statically is a restriction. But
we're imposing restrictions anyway, supposedly catering to some common
> Here are some other interesting questions:
> * Is a library invoked just once at meta-level N no matter how many times
> and from where eval is called at run time?
> Yes, I think.
> * If meta-level N code calls eval to evaluate an expression x, is x
> treated as if it too were at meta-level N?
> Yes, I think. This would probably require a level variable to be bound
> dynamically by the expander and referenced by eval.
I agree on both counts. But should the `eval' meta-levels really be
the same as the expansion meta-levels?
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
More information about the R6RS