[R6RS] Eval vs. phases

dyb at cs.indiana.edu dyb at cs.indiana.edu
Thu Jul 13 10:42:13 EDT 2006


> I didn't make my question very clear.  My question is not about the
> semantics of visiting or loading---it's about what identifiers are
> visible.  The way I understand the library proposal, the import phase
> controls what identifiers are visible in "regular" code and what
> identifiers are visible in macro transformers.  I was expecting that
> this distinction is preserved even in Model 1.

When imported "for expand" in Model 1, the import is visible at all meta
levels at expand time.  Similarly, when imported "for eval" in Model 1,
the import is visible at all meta levels at run time.  We could have this
rule for Model 2 as well; the only reason we believe a more precise
declaration for Model 2 is because, in Model 2, the library has to be
loaded (invoked) at each level for which its exports are accessed, and
since invoking a library has side effects, implicitly invocation based on
whether a reference happens to appear in a given meta level seems like a
bad idea.

> Consider a library module `helper' exporting `foo'.  Now I have a
> library with:
>
> (import (for helper run))
>
> (define-syntax bar
>   (lambda (x)
>     ... foo ...))
>         ^^^^ not visible in the absence of other imports for `foo'
>  
> Right?

Right.  But if you have a library with:

(import (for helper expand))

(define-syntax bar
  (lambda (x)
    (define-syntax bar-bar
      (lambda (x)
         ... foo ...))
    ... foo ...))

both references to foo are valid because importing "for expand" makes
the binding available at all meta levels.

> Now, if I say
>
> (import (for helper eval))
>
> Does the binding for `foo' show up in "regular" code *and* in macro
> expanders?  If not in macro expanders, how do I make it show up?

It shows up in "regular" code *and* in macro expanders.

In Model 1, the (for --- phase ...) syntax determines whether the expand-
and run-time information is available in a given phase.  If it's available,
there's no restriction on accessing it.  "for eval" makes both the
expand- and run-time information available at run time, where it can
be used by all meta levels of an eval'd expression.

Kent



More information about the R6RS mailing list