Thoughts so far: I think you need a new communication channel to get information from the expansion of an enclosing module to the expansion of its submodule.
Expansion-time state is the right kind of channel, but I think it's important to start every submodule's expansion in a fresh store, at least usually. Otherwise, many syntactic extensions won't work correctly in a submodule. To give the programmer more control, we could add a `local-expand-submodule' function that is like `local-expand', but (1) it works only for `module' and `module*' forms in a 'module context, and (2) it accepts module paths to attach from the current expansion context to the submodule's expansion context. Using this addition, when expanding a `(module* name #f ....)' submodule, Typed Racket could attach a compile-time module that houses the "in a typed context" flag --- the same one that Typed Racket's `#%module-begin' sets. Does it sound like that would work? I worry that `local-expand-submodule' might be used to break a syntactic form by attaching a module that isn't intended to be attached to multiple expansion stores. I think a macro that abuses `local-expand-submodule' could only harm itself or some other module that trusts the macro, but it's difficult to be sure. At Mon, 25 Jun 2012 16:47:36 -0600, Matthew Flatt wrote: > At Mon, 25 Jun 2012 17:50:27 -0400, Sam Tobin-Hochstadt wrote: > > The problem (I > > think) is that the implicit `require` of `(submod "..")` happens > > *before* the expansion of `#%module-begin` inside the submodule. > > That's the same for a top-level module M whose initial language is some > other module L, right? The require of `L' happens before the > `#%module-begin' expansion in `M'... and it can't be any other way, > because `#%module-begin' comes from `L'. > > > The > > key bit of code is the residual snippet left in the outer module: > > > > (begin-for-syntax > > (when (unbox is-typed?) > > (set-box! type-env 1))) > > > > Currently, in TR, the code in the begin-for-syntax is unconditional, > > and therefore it gets re-run in the store used for expanding the inner > > submodule. However, if I add the `when`, then the `set-box!` doesn't > > happen, and the expansion of `m` fails. I'd like to be able to add > > this conditional, so I'd like to change the order of effects slightly > > here. > > I see what you mean, but I don't think it makes sense to change the > order of things in the way that you're suggesting. I don't have any > immediate ideas, but I'll think about it more. > > > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev