[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