[R6RS] Eval vs. phases
dyb at cs.indiana.edu
dyb at cs.indiana.edu
Tue Aug 1 11:12:51 EDT 2006
> > 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.
Sorry for being unclear. I was refering to the fact that a transformer
used during the compilation of a library could call eval.
> > 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.
I would be unhappy with such a restriction. If we're going to have eval
in the language, I want it to work for arbitrary expressions. I can stick
(for-eval --- (meta 0) (meta 1) (meta 2) ... (meta N)) in my program and
lift the restriction to an arbitrary level N, but for any N I pick there
are programs I won't be able to eval, and if I choose some large N in the
hope that the restriction won't matter in practice, I'll end up invoking
the listed libraries some large number of times, probably unnecessarily.
> I agree on both counts. But should the `eval' meta-levels really be
> the same as the expansion meta-levels?
I don't know what you mean---please clarify.
Kent
More information about the R6RS
mailing list