On Mon, Jun 25, 2012 at 6:53 PM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > Sam, can you focus on cases of submodules for which you can guarantee that > #%module-begin is okay and reject others [with an explicit, informative error > message]? -- Matthias
I'm not entirely sure what you mean here, but: (a) this discussion is just about enabling an optimization, which I thus won't for the immediate future. This is an important optimization, and one that's a step towards removing the overhead of using Typed Racket, but it's still an optimization and I can do without it. (b) the affected submodules include everything that uses `module+`, so rejecting those isn't really an option. Sam > > > On Jun 25, 2012, at 6:47 PM, 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 > -- sam th sa...@ccs.neu.edu _________________________ Racket Developers list: http://lists.racket-lang.org/dev