Is it possible there is another channel that TR could use to communicate these types? That is, could it not expand
(: f Integer) (define f 5) into something that bound 'f' to a macro that knows its type? I guess it already does that, so something doesn't work about that here, but I'm not seeing what it is. Robby On Mon, Jul 2, 2012 at 8:07 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > 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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev