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

At Tue, 3 Jul 2012 11:14:10 -0400, Sam Tobin-Hochstadt wrote:
> On Tue, Jul 3, 2012 at 11:08 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> > At Tue, 3 Jul 2012 11:05:52 -0400, Sam Tobin-Hochstadt wrote:
> >> However, I don't (yet) think it's the right solution.  In particular,
> >> I feel like this moves away from the really great feature of
> >> submodules, which is that they behave basically exactly like regular
> >> modules.  From what I can tell, the only place where this uniformity
> >> breaks down currently is with `(module* name #f ....)', where the
> >> outer module is `require`d *before* the inner module starts expanding.
> >>  In other words, if we have:
> >>
> >> (module M L
> >>    (module* N #f ...))
> >>
> >> currently `M` is required *before* `N` begins expanding, which is
> >> unlike any other module relationship that can be expressed in Racket
> >> (I think).
> >
> > How does it differ from
> >
> >  (module M L ....)
> >  (module N M ....)
> 
> You're totally right.  Good thing I added that "(I think)" qualifier. :)
> 
> However, I think of the submodule case as more like:
> 
>   (module M L ....)
>   (module N L (require M) ....)
> 
> except with the ability to see more of `M` than `require` normally exposes.

It's really more like `(module N M ...)'. Here's an example to
illustrate the difference:

 #lang racket/base

 (define-syntax-rule (#%module-begin) ; shadows `racket/base' version
   (#%plain-module-begin (displayln "Hi")))

 (module+ main) ; prints "Hi"

> Thinking further about your example, I think that it would also break
> the conditional environment updates that I'm thinking of.  I think
> that means that I need to go back to the drawing board and think about
> the requirements here.

Ok.