[plt-scheme] Evaling syntax with module bindings

On Mon, Jan 30, 2006 at 12:00:13AM +0200, Lauri Alanko wrote:
> > (module a mzscheme (provide xa) (define xa 42))
> > (module b mzscheme
> (require-for-template mzscheme a) (provide xb) (define xb #'xa))
> > (require b)
> > (define ns (make-namespace))
> > (eval xb ns)
> reference to undefined identifier: xa

As so often happens, immediately after asking the question I found the
answer. Well, some kind of an answer anyway. It all works when I replace
require-for-template with require in module b. Then, whatever namespace
I happen to evaluate xb in, it just has to contain a module named a,
which I can either attach there or define explicitly (even differently).

I have a vague idea of why it works like this. The require-for-template
tells where identifiers in the current module are bound when the
identifiers are used as the result of syntax transformation (i.e. in the
next phase). And require tells where the identifiers are bound when used
in the current phase. It's very easy to think that the distinction is
between identifiers in (syntax ...) and identifiers outside it, but
that's of course only an accidental consequence of the way syntax
objects are usually used.

The problem with this, as my example demonstrated, is that now a module
that exports variables bound to syntax objects must know how they are
used by others: if they are used by syntax transformers, then the
correct scope should be indicated by require-for-template. If they are
used by eval, then the scope should be indicated by require. This seems
wrong: the providing module should not be required to know such matters.

Perhaps the fundamental issue is with eval: the evaled code is
considered to be in the same phase as the code calling eval, even though
conceptually there is a phase separation. Is it possible to have a
variant of eval that, when given a syntax object as an argument, would
use the "next-phase" bindings instead of the "current-phase" bindings? 
In effect, acting like the syntax object was just returned by a syntax
transformer?

This could probably be simulated by creating in namespace ns a syntax
definition that was bound to a syntax transformer that returned the
syntax object xb, but I can't quite see how to dynamically bind syntax
transformers in a namespace. namespace-set-variable-value! only binds a
value.

In any case, my immediate problem seems to be solvable reasonably
enough, so I'm not really complaining.


Lauri