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

On Mon, Jun 25, 2012 at 5:14 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> The expansion of submodules is intended to have a fresh store, just
> like the expansion of any module. The `#f' initial import is intended
> to be something like using `(submod "..")' as the initial language,
> except importing all internal bindings of the module instead of its
> exports.
>
> Can Typed Racket not handle enclosing bindings in the same way that it
> handles `require's in general?

Currently, it can.  However, I wanted to make a fairly small change to
only update the type environment when needed, and it broke because of
this.  In the context of my example, the `(m)` invocation is expanded
*before* the inner `#%module-begin` expansion happens, meaning that it
hits the error case, even though it's expanded inside a module with
the appropriate `#%module-begin` binding.

With submodules as they currently work, the inner `#%module-begin` is
expanded quite late, which I think breaks other possible expectations
about #%module-begin as well.  Moving it earlier will, I think,
alleviate all of these issues.

>
> At Mon, 25 Jun 2012 17:05:21 -0400, Sam Tobin-Hochstadt wrote:
>> It appears that the expansion of (module* m #f ...) occurs in a fresh
>> store, but before running the inner module's `#%module-begin` binding.
>> To see this, run the program at https://gist.github.com/2991214 , and
>> note that ">> in module-begin" is printed only once, but the expansion
>> of `m` fails, indicating a fresh store.
>>
>> This is troublesome for Typed Racket, which uses the store to record
>> the types of identifiers. Is this the intended behavior?
>> --
>> sam th
>> samth at ccs.neu.edu



-- 
sam th
samth at ccs.neu.edu