[plt-scheme] Evaling syntax with module bindings

At Mon, 30 Jan 2006 00:00:13 +0200, Lauri Alanko wrote:
> I need syntax objects that refer to a variable in a particular module.
> This is how it works normally:
> 
> > (module a mzscheme (provide xa) (define xa 42))
> > (module b mzscheme
> (require-for-template mzscheme a) (provide xb) (define xb #'xa))
> > (require-for-syntax b)
> > (define-syntax (foo stx) xb)
> > (foo)
> reference to an identifier before its definition: xa in module: a

The flaky top level strikes again... I'm not yet sure what to do here.

If you just want to compile an expression (without evaluating it), then
the `require-for-template'd module doesn't need to be evaluated. That
argues in favor of the above behavior. In fact, some of our
program-processing tools rely on this behavior (as they muddle through
in top-level mode).

But I'm not sure the tools should rely on the current behavior. I'll
leave things alone for now, but I'll think about it more.

At Mon, 30 Jan 2006 01:04:22 +0200, Lauri Alanko wrote:
> 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.

I'm pretty sure I disagree with you on this conclusion. It seems to me
that the providing module should know how its exported identifiers are
used (at least in terms of phase).

> 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?

`eval-for-syntax' and `eval-for-template'? They make sense in
principle, but I doubt that they're the right solution to this problem.

Maybe you should compile a `module' expression instead of a top-level
expression, and then evaluate the compiled module in a different
namespace (with a different `a'). Is that possible in your case? In the
long run, you might avoid other top-level headaches that way.

Matthew