[R6RS] Eval vs. phases

[Michael Sperber]

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

> 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