At Tue, 3 Jul 2012 11:14:10 -0400, Sam Tobin-Hochstadt wrote: > On Tue, Jul 3, 2012 at 11:08 AM, Matthew Flatt <mfl...@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. _________________________ Racket Developers list: http://lists.racket-lang.org/dev
