[plt-scheme] multiple invocation via require-for-syntax
PLT people-
Just trying to further digest MzScheme's module system...
A piece of code I am working on porting maintains some shared state at
syntax expansion time. The shared state is declared in one module and
then modified by other modules at syntax-expansion time.
However, it seems like each call to REQUIRE-FOR-SYNTAX is invoking a
new version of the core module, redefining the state component to its
initial value and then modifying that private copy. That is, each
client has its own copy of module, and so the modifications are not
shared between the clients.
From the MzScheme language manual, section 5.1:
> When a module declaration is evaluated, the module's body is
> syntax-expanded and compiled, but not executed. The body is executed
> only when the module is explicitly invoked, via a require or
> require-for-syntax expression at the top level, or a call to
> dynamic-require. When a module is invoked, its body definitions and
> expressions are evaluated. First, however, the definitions and
> expressions are evaluated for each module imported (via require) by
> the invoked module. The import-initialization rule applies up the
> chain of modules, so that every module used (directly or indirectly)
> by the invoked module is executed before any module that uses its
> exports. A module can only import from previously declared modules, so
> the module-import relationship is acyclic.
>
> Every module is executed at most once in response to an invocation,
> regardless of the number of times it is imported into other modules.
> Every top-level invocation executes only the modules needed by the
> invocation that have not been executed by previous invocations.
This last paragraph implies (to me) that the single-invocation rule
should apply to both modules instantiated with REQUIRE-FOR-SYNTAX.
That is,
(module A ...)
(module B mzscheme (require-for-syntax a) ...)
(module C mzscheme (require-for-syntax a) ...)
(module D mzscheme (require b c) ...)
One would think that B and C would share the same copy of the A module
at syntax-expansion time. Is there a technical reason why they would
not (by design, that is)? Perhaps there is a conflict with allowing
separate compilation; in any case, if the current REQUIRE-FOR-SYNTAX
behavior is not erroneous, then I think the manual is a bit misleading
in its description of the single-invocation rule.
If anyone can give me any hints as to how I could accomplish something
like what I describe above, I would appreciate it. (Here's a little
more context: I'm trying to port Edwin's OOP system, which builds a
class representation at syntax-expansion time with mappings from
slot-names to slot-indices, and then during syntax-expansion it
replaces occurrences of the slot-names with vector-ref's at the right
index in the given object. For this to work across module boundaries,
separate modules must have access to the same set of class-definitions,
which is modified whenever a class definition construct is encountered)
I've attached a scheme source file that attempts to illustrate the
difference in behavior, as well as a transcript of its output.
Sincerely,
-Felix
p.s. on an unrelated tangent, note that in mzmod.scm that I couldn't
use my DISPLN procedure within define-syntax definitions. Is there a
way to get a language module to do something like (provide-for-syntax
displn), so that people writing in that language do not have to add an
additional require-for-syntax statement? (Alternatively, perhaps using
a language module should implicitly both REQUIRE and REQUIRE-FOR-SYNTAX
that module?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mzmod.scm
Type: application/octet-stream
Size: 2170 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20030728/6ec9f7d6/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mzmod.transcript
Type: application/octet-stream
Size: 1794 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20030728/6ec9f7d6/attachment-0001.obj>
-------------- next part --------------