Re: wrapping `define-syntax'

[Julian Graham <joolean@gmail.com>]

Hi Andy,

> The final paragraph of 7.2 seems to imply that these additional bindings
> may also be present for the runtime phase, which would obviate the need
> for the temporary modules.

I take it you're referring to this sentence?

"When an identifier appears as an expression in a phase that is
inconsistent with the identifier’s level, then an implementation may
raise an exception either at expand time or run time, or it may allow
the reference."

Yeah, you're right -- I'd forgotten about this.  (This totally sounds
like another case of R6RS accommodating existing implementations with
complicated behavior while letting new ones off the hook.)


> This means you have to give names to those intermediate modules, because
> syncase's output has to be serializable. It doesn't seem like named
> temporary modules are a good idea.

Fair enough, although this makes me curious about uniqueness
constraints on module names in the context of syncase -- I'm guessing
that `@' and `@@' rely on the global registry that `define-module'
writes to (and to which `make-module' doesn't).  What would you
recommend with regard to naming and registering dynamically-created
modules / interfaces?

This probably belongs on guile-devel, but what I'm getting at is that
the `import' form allows for the creation of interfaces layered on top
of interfaces to an arbitrarily deep extent.  So it looks like R6RS
library support's gonna need a way to serialize the export interface
of a module that's created dynamically (as an interface to another
module / interface) in order to provide a unique name for that module
so that `@' and `@@' can refer to it.


> Why not import the bindings needed at expansion time, evaluate keyword
> definitions, then import other bindings needed at runtime, then evaluate
> variable definitions and expressions? No temporary modules would be
> necessary.

Well, it's a little bit more involved, since local syntax definitions
(`let-syntax' etc.) also require phased imports -- could we import
phased bindings for "meta" phases >= 2 at the same time we bring in
the "expand" phase bindings?


Regards,
Julian