[racket-dev] Trouble with state, submodules, and module-begin

On Mon, Jun 25, 2012 at 6:53 PM, Matthias Felleisen
<matthias at 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
samth at ccs.neu.edu