Re: [racket-dev] submodules and local-expand
At Wed, 6 Jun 2012 13:32:19 -0400, Sam Tobin-Hochstadt wrote: However, we can't just add `module*` to the stop list at the moment, because if anything is in the stop list, then all the core forms are added, and then we wouldn't fully expand the program. However, I think we can relax this restriction in the case of `module*`. In particular, if the stop list contains *only* `module*`, then we should avoid adding the other core forms. That sounds right to me. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
At Fri, 9 Mar 2012 17:21:26 -0700, Matthew Flatt wrote: At Fri, 9 Mar 2012 15:58:11 -0700, Jay McCarthy wrote: I just pushed... - module** Like module* but combines multiple occurrences of the same submodule name into one module* I like this direction --- and like everyone, I wish for a better name. As you probably noticed, we're currently trying out `module+'. I tried out several alternatives, including `submodule', `slice', `facet', `segment', `section', `.section', `at-module', and even `p.s.'; `module+' is the best so far. One big advantage of `module+' is that it avoids inventing a new term, and I think `+' is suggestive of combining multiple bodies into one. Meanwhile, `(submod ..)' is now allowed as a shorthand for `(submod . ..)'. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
Sorry Matthias, I don't think I understand your question. At the bytecode level, it would be easy, so we could change the distribution scripts to do that. At the source level, it's not really possible because of macros that generate code in a submodule. My personal taste is that it is bad to ship .rkt that doesn't compile, but I'd also like a future where we don't ship .rkt Jay On 3/12/12, Matthias Felleisen matth...@ccs.neu.edu wrote: On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Meaning? Removing docs and tests shouldn't leave the functional part in bad shape Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
Why does it not compile? Do you mean it doesn't compile to the same byte codes? On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote: Sorry Matthias, I don't think I understand your question. At the bytecode level, it would be easy, so we could change the distribution scripts to do that. At the source level, it's not really possible because of macros that generate code in a submodule. My personal taste is that it is bad to ship .rkt that doesn't compile, but I'd also like a future where we don't ship .rkt Jay On 3/12/12, Matthias Felleisen matth...@ccs.neu.edu wrote: On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Meaning? Removing docs and tests shouldn't leave the functional part in bad shape Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
He's saying that there is no easy way to, without expanding the code (and perhaps without going one step further beyond a fully expanded program, but nevermind that detail), split apart the submodules that come from a single module. You just cannot tell, without expanding everything, which of the imports end up being used where (at least I think that's the idea). Robby On Mon, Mar 12, 2012 at 1:47 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Why does it not compile? Do you mean it doesn't compile to the same byte codes? On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote: Sorry Matthias, I don't think I understand your question. At the bytecode level, it would be easy, so we could change the distribution scripts to do that. At the source level, it's not really possible because of macros that generate code in a submodule. My personal taste is that it is bad to ship .rkt that doesn't compile, but I'd also like a future where we don't ship .rkt Jay On 3/12/12, Matthias Felleisen matth...@ccs.neu.edu wrote: On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Meaning? Removing docs and tests shouldn't leave the functional part in bad shape Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
I know that. But we could consider the pruning step as part of compilation. On Mar 12, 2012, at 2:57 PM, Robby Findler wrote: He's saying that there is no easy way to, without expanding the code (and perhaps without going one step further beyond a fully expanded program, but nevermind that detail), split apart the submodules that come from a single module. You just cannot tell, without expanding everything, which of the imports end up being used where (at least I think that's the idea). Robby On Mon, Mar 12, 2012 at 1:47 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Why does it not compile? Do you mean it doesn't compile to the same byte codes? On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote: Sorry Matthias, I don't think I understand your question. At the bytecode level, it would be easy, so we could change the distribution scripts to do that. At the source level, it's not really possible because of macros that generate code in a submodule. My personal taste is that it is bad to ship .rkt that doesn't compile, but I'd also like a future where we don't ship .rkt Jay On 3/12/12, Matthias Felleisen matth...@ccs.neu.edu wrote: On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Meaning? Removing docs and tests shouldn't leave the functional part in bad shape Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
Yes, I think the point that Jay's making is that the thing you'd distribute wouldn't be rkt code, but some low-level thing. Well, either that or you distribute .rkt code that doesn't actually run. Robby On Mon, Mar 12, 2012 at 1:59 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I know that. But we could consider the pruning step as part of compilation. On Mar 12, 2012, at 2:57 PM, Robby Findler wrote: He's saying that there is no easy way to, without expanding the code (and perhaps without going one step further beyond a fully expanded program, but nevermind that detail), split apart the submodules that come from a single module. You just cannot tell, without expanding everything, which of the imports end up being used where (at least I think that's the idea). Robby On Mon, Mar 12, 2012 at 1:47 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Why does it not compile? Do you mean it doesn't compile to the same byte codes? On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote: Sorry Matthias, I don't think I understand your question. At the bytecode level, it would be easy, so we could change the distribution scripts to do that. At the source level, it's not really possible because of macros that generate code in a submodule. My personal taste is that it is bad to ship .rkt that doesn't compile, but I'd also like a future where we don't ship .rkt Jay On 3/12/12, Matthias Felleisen matth...@ccs.neu.edu wrote: On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Meaning? Removing docs and tests shouldn't leave the functional part in bad shape Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
Or you make the pruning step a part of the compiler. On Mar 12, 2012, at 3:01 PM, Robby Findler wrote: Yes, I think the point that Jay's making is that the thing you'd distribute wouldn't be rkt code, but some low-level thing. Well, either that or you distribute .rkt code that doesn't actually run. Robby On Mon, Mar 12, 2012 at 1:59 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I know that. But we could consider the pruning step as part of compilation. On Mar 12, 2012, at 2:57 PM, Robby Findler wrote: He's saying that there is no easy way to, without expanding the code (and perhaps without going one step further beyond a fully expanded program, but nevermind that detail), split apart the submodules that come from a single module. You just cannot tell, without expanding everything, which of the imports end up being used where (at least I think that's the idea). Robby On Mon, Mar 12, 2012 at 1:47 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Why does it not compile? Do you mean it doesn't compile to the same byte codes? On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote: Sorry Matthias, I don't think I understand your question. At the bytecode level, it would be easy, so we could change the distribution scripts to do that. At the source level, it's not really possible because of macros that generate code in a submodule. My personal taste is that it is bad to ship .rkt that doesn't compile, but I'd also like a future where we don't ship .rkt Jay On 3/12/12, Matthias Felleisen matth...@ccs.neu.edu wrote: On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Meaning? Removing docs and tests shouldn't leave the functional part in bad shape Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
Yes: In other words, there could be a parameter that causes the macro expander to drop `test' submodules before it even attempts to expand them --- roughly like not using `-g' with `gcc'. Meanwhile, the after-the-fact pruning tool could be called `raco strip'. At Mon, 12 Mar 2012 15:02:58 -0400, Matthias Felleisen wrote: Or you make the pruning step a part of the compiler. On Mar 12, 2012, at 3:01 PM, Robby Findler wrote: Yes, I think the point that Jay's making is that the thing you'd distribute wouldn't be rkt code, but some low-level thing. Well, either that or you distribute .rkt code that doesn't actually run. Robby On Mon, Mar 12, 2012 at 1:59 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I know that. But we could consider the pruning step as part of compilation. On Mar 12, 2012, at 2:57 PM, Robby Findler wrote: He's saying that there is no easy way to, without expanding the code (and perhaps without going one step further beyond a fully expanded program, but nevermind that detail), split apart the submodules that come from a single module. You just cannot tell, without expanding everything, which of the imports end up being used where (at least I think that's the idea). Robby On Mon, Mar 12, 2012 at 1:47 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Why does it not compile? Do you mean it doesn't compile to the same byte codes? On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote: Sorry Matthias, I don't think I understand your question. At the bytecode level, it would be easy, so we could change the distribution scripts to do that. At the source level, it's not really possible because of macros that generate code in a submodule. My personal taste is that it is bad to ship .rkt that doesn't compile, but I'd also like a future where we don't ship .rkt Jay On 3/12/12, Matthias Felleisen matth...@ccs.neu.edu wrote: On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Meaning? Removing docs and tests shouldn't leave the functional part in bad shape Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
Ya, even if someone does their best by moving dependencies into the tightest module*, there is a compilation problem: m.rk #lang racket (module* test #f (require tests/eli-tester)) simply does not compile if tests/eli-tester is not there. If you did compile it but didn't instantiate the test module, then it would run just fine (even without zo stripping) Jay On 3/12/12, Robby Findler ro...@eecs.northwestern.edu wrote: He's saying that there is no easy way to, without expanding the code (and perhaps without going one step further beyond a fully expanded program, but nevermind that detail), split apart the submodules that come from a single module. You just cannot tell, without expanding everything, which of the imports end up being used where (at least I think that's the idea). Robby On Mon, Mar 12, 2012 at 1:47 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Why does it not compile? Do you mean it doesn't compile to the same byte codes? On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote: Sorry Matthias, I don't think I understand your question. At the bytecode level, it would be easy, so we could change the distribution scripts to do that. At the source level, it's not really possible because of macros that generate code in a submodule. My personal taste is that it is bad to ship .rkt that doesn't compile, but I'd also like a future where we don't ship .rkt Jay On 3/12/12, Matthias Felleisen matth...@ccs.neu.edu wrote: On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Meaning? Removing docs and tests shouldn't leave the functional part in bad shape Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
Oh, I get it now. Thanks. This also seems like something that you'd want to put control over at the package level, I guess. That is, a package can depend on another package, but without that second package's test modules or something. Robby On Mon, Mar 12, 2012 at 2:05 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Yes: In other words, there could be a parameter that causes the macro expander to drop `test' submodules before it even attempts to expand them --- roughly like not using `-g' with `gcc'. Meanwhile, the after-the-fact pruning tool could be called `raco strip'. At Mon, 12 Mar 2012 15:02:58 -0400, Matthias Felleisen wrote: Or you make the pruning step a part of the compiler. On Mar 12, 2012, at 3:01 PM, Robby Findler wrote: Yes, I think the point that Jay's making is that the thing you'd distribute wouldn't be rkt code, but some low-level thing. Well, either that or you distribute .rkt code that doesn't actually run. Robby On Mon, Mar 12, 2012 at 1:59 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I know that. But we could consider the pruning step as part of compilation. On Mar 12, 2012, at 2:57 PM, Robby Findler wrote: He's saying that there is no easy way to, without expanding the code (and perhaps without going one step further beyond a fully expanded program, but nevermind that detail), split apart the submodules that come from a single module. You just cannot tell, without expanding everything, which of the imports end up being used where (at least I think that's the idea). Robby On Mon, Mar 12, 2012 at 1:47 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Why does it not compile? Do you mean it doesn't compile to the same byte codes? On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote: Sorry Matthias, I don't think I understand your question. At the bytecode level, it would be easy, so we could change the distribution scripts to do that. At the source level, it's not really possible because of macros that generate code in a submodule. My personal taste is that it is bad to ship .rkt that doesn't compile, but I'd also like a future where we don't ship .rkt Jay On 3/12/12, Matthias Felleisen matth...@ccs.neu.edu wrote: On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Meaning? Removing docs and tests shouldn't leave the functional part in bad shape Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
I thought Matthew was pointing out how we can distribute some source that works if you set a parameter properly and that same source will contain no test-based dependencies. Boy, this conversation sure makes me wish for the ability to just gather everyone up around a whiteboard or something :( Robby On Mon, Mar 12, 2012 at 2:15 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I think Jay is expressing an Eli-concern: we need to distribute the full source to determine whether something can be thrown away. On Mar 12, 2012, at 3:13 PM, Robby Findler wrote: Oh, I get it now. Thanks. This also seems like something that you'd want to put control over at the package level, I guess. That is, a package can depend on another package, but without that second package's test modules or something. Robby On Mon, Mar 12, 2012 at 2:05 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Yes: In other words, there could be a parameter that causes the macro expander to drop `test' submodules before it even attempts to expand them --- roughly like not using `-g' with `gcc'. Meanwhile, the after-the-fact pruning tool could be called `raco strip'. At Mon, 12 Mar 2012 15:02:58 -0400, Matthias Felleisen wrote: Or you make the pruning step a part of the compiler. On Mar 12, 2012, at 3:01 PM, Robby Findler wrote: Yes, I think the point that Jay's making is that the thing you'd distribute wouldn't be rkt code, but some low-level thing. Well, either that or you distribute .rkt code that doesn't actually run. Robby On Mon, Mar 12, 2012 at 1:59 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I know that. But we could consider the pruning step as part of compilation. On Mar 12, 2012, at 2:57 PM, Robby Findler wrote: He's saying that there is no easy way to, without expanding the code (and perhaps without going one step further beyond a fully expanded program, but nevermind that detail), split apart the submodules that come from a single module. You just cannot tell, without expanding everything, which of the imports end up being used where (at least I think that's the idea). Robby On Mon, Mar 12, 2012 at 1:47 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Why does it not compile? Do you mean it doesn't compile to the same byte codes? On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote: Sorry Matthias, I don't think I understand your question. At the bytecode level, it would be easy, so we could change the distribution scripts to do that. At the source level, it's not really possible because of macros that generate code in a submodule. My personal taste is that it is bad to ship .rkt that doesn't compile, but I'd also like a future where we don't ship .rkt Jay On 3/12/12, Matthias Felleisen matth...@ccs.neu.edu wrote: On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Meaning? Removing docs and tests shouldn't leave the functional part in bad shape Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
I agree with Robby. Jay On Mon, Mar 12, 2012 at 1:18 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I thought Matthew was pointing out how we can distribute some source that works if you set a parameter properly and that same source will contain no test-based dependencies. Boy, this conversation sure makes me wish for the ability to just gather everyone up around a whiteboard or something :( Robby On Mon, Mar 12, 2012 at 2:15 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I think Jay is expressing an Eli-concern: we need to distribute the full source to determine whether something can be thrown away. On Mar 12, 2012, at 3:13 PM, Robby Findler wrote: Oh, I get it now. Thanks. This also seems like something that you'd want to put control over at the package level, I guess. That is, a package can depend on another package, but without that second package's test modules or something. Robby On Mon, Mar 12, 2012 at 2:05 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Yes: In other words, there could be a parameter that causes the macro expander to drop `test' submodules before it even attempts to expand them --- roughly like not using `-g' with `gcc'. Meanwhile, the after-the-fact pruning tool could be called `raco strip'. At Mon, 12 Mar 2012 15:02:58 -0400, Matthias Felleisen wrote: Or you make the pruning step a part of the compiler. On Mar 12, 2012, at 3:01 PM, Robby Findler wrote: Yes, I think the point that Jay's making is that the thing you'd distribute wouldn't be rkt code, but some low-level thing. Well, either that or you distribute .rkt code that doesn't actually run. Robby On Mon, Mar 12, 2012 at 1:59 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I know that. But we could consider the pruning step as part of compilation. On Mar 12, 2012, at 2:57 PM, Robby Findler wrote: He's saying that there is no easy way to, without expanding the code (and perhaps without going one step further beyond a fully expanded program, but nevermind that detail), split apart the submodules that come from a single module. You just cannot tell, without expanding everything, which of the imports end up being used where (at least I think that's the idea). Robby On Mon, Mar 12, 2012 at 1:47 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Why does it not compile? Do you mean it doesn't compile to the same byte codes? On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote: Sorry Matthias, I don't think I understand your question. At the bytecode level, it would be easy, so we could change the distribution scripts to do that. At the source level, it's not really possible because of macros that generate code in a submodule. My personal taste is that it is bad to ship .rkt that doesn't compile, but I'd also like a future where we don't ship .rkt Jay On 3/12/12, Matthias Felleisen matth...@ccs.neu.edu wrote: On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: The current demodularizer would do that. Presumably we could make a tool that operated on a single module's zo and removed such submodules. The main problem would be that the source is un-compilable. Meaning? Removing docs and tests shouldn't leave the functional part in bad shape Jay On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes, dependencies abound if we include tests and doc in the same module. At the same time it is good practice to have things together. Can't this problem be solved with module-flattening tools? From what I can tell, these test and doc modules could be dropped leaving the running residual, which could be bundled. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
On Mar 10, 2012, at 6:26 PM, Eli Barzilay wrote: I first thought that the whole point of allowing a sub-`module' would be to have some otherwise-inaccessible private code in it (as the fictitious author of that `my-code' module thinks). I second this impression, as I have done in previous private message. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
At Sat, 10 Mar 2012 18:26:52 -0500, Eli Barzilay wrote: Perhaps a more obvious question is why aren't all `submod' uses get . as an implicit first expression? I don't see how lets you reach a submodule from the top level or from within a different top-level module. So, this is the bit that wasn't clear to me in your original email. I now see that this code works: | #lang racket/load | | (module my-code racket/base | (module private racket/base | (provide secret) | (define secret 1)) | (require 'private) | (provide public) | (define public (list secret))) | | (module hacker racket/base | (require (submod 'my-code private)) | (printf The secret is ~a\n secret)) | | (require 'hacker) Isn't this kind of code something that doesn't have a real use, perhaps other than some reflection stuff (like repl uses)? If I understand what you mean, then all of the interesting uses I see involve extracting a submodule from the outside: * Extracting the `reader' submodule of a given module. * Running a `main' submodule of a given module. * Running a `test' submodule of a given module. * Getting documentation information for a given module. * Getting extra exports of a given module. I expect submodule references across top-level modules, as in your example above, to be relatively rare, but that's what would happen for getting extra exports. Also, a reader for language X might want to just re-export the reader for language Y. I first thought that the whole point of allowing a sub-`module' would be to have some otherwise-inaccessible private code in it (as the fictitious author of that `my-code' module thinks). That is indeed not the goal. But it works the other direction with `(submodule* ... #f )': the enclosing module can have otherwise-inaccessible code that is accessed by the submodule (e.g., to test unexported functions). If that's wasn't possible, or possible only as a some semi-obscure-reflection-api then the `submod' syntax could be simpler. I'm not sure what you mean here . I also love the analogy to paths -- but using strings for them doesn't look so nice, since strings are begging to be combined... (I can already see myself wishing for ./../foo.) Other than the obvious reader issue, would there be a problem in using `|.|' and `..' for these (and making them into special module names)? Submodule identifiers are not currently constrained, and I think we should avoid constraining them. If we refrain from constraining submodule names, then `..' could be the name of a submodule. It just seems similar to the old (lib.ss some path) thing in that it's asking to be changed to something that is easier to remember. Maybe make .. have an implicit . before it so there's no need for a mysterious `. ..'? Yes, I think `(submod .. elem ...)' can be a shorthand for `(submod . .. elem ...)'. I see no way to handle it other than as a special case, but that seems ok. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
An hour and a half ago, Matthew Flatt wrote: If I understand what you mean, then all of the interesting uses I see involve extracting a submodule from the outside: * Extracting the `reader' submodule of a given module. * Running a `main' submodule of a given module. * Running a `test' submodule of a given module. * Getting documentation information for a given module. * Getting extra exports of a given module. Ah, obviously... I can trace the reason I didn't see these as obvious cases to the same little dependency graph I wrote about earlier: sub-`module*' ⇢ module ⇢ sub-`module' Looks like the above items would all be on the left `module*' side, and on that side it makes sense for the submodules on that side to be public since otherwise there's no use for them. So maybe there's a case for `module*' to be visible and for `module' to be hidden? I can't think of practical cases where a submodule on the right side should be visible to the outside. Hopefully this will be clear: for a sub-`module' to be visible on the right, it needs to have some excuse for being a sub-`module', but since there's no way to require the main module from these sub-modules, I no reason for them to be sub-`module's rather than sub-`module*'s. IOW, I think that even a code-repository kind of thing could be done with sub-`module*'s. I first thought that the whole point of allowing a sub-`module' would be to have some otherwise-inaccessible private code in it (as the fictitious author of that `my-code' module thinks). That is indeed not the goal. But it works the other direction with `(submodule* ... #f )': the enclosing module can have otherwise-inaccessible code that is accessed by the submodule (e.g., to test unexported functions). (This sounds like a point that supports what I said above.) If that's wasn't possible, or possible only as a some semi-obscure-reflection-api then the `submod' syntax could be simpler. I'm not sure what you mean here. (I was talking about not allowing submodules to be visible. Clarifying the above first would help here, probably.) I also love the analogy to paths -- but using strings for them doesn't look so nice, since strings are begging to be combined... (I can already see myself wishing for ./../foo.) Other than the obvious reader issue, would there be a problem in using `|.|' and `..' for these (and making them into special module names)? Submodule identifiers are not currently constrained, and I think we should avoid constraining them. If we refrain from constraining submodule names, then `..' could be the name of a submodule. It just seems similar to the old (lib.ss some path) thing in that it's asking to be changed to something that is easier to remember. Maybe make .. have an implicit . before it so there's no need for a mysterious `. ..'? Yes, I think `(submod .. elem ...)' can be a shorthand for `(submod . .. elem ...)'. I see no way to handle it other than as a special case, but that seems ok. The main benefit I see in this is to supress the obvious desire to combine them with ./... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
I agree with your point #1 heartily. I don't follow point #2. Do you mean that currently by having two files the tests can depend on things that the code does not (for purposes of distribution, etc) and having those tests embedded in the files increases the cross-collection dependencies as well as increasing compilation time? I suppose that is true, but I don't know how severe it is and I value having the tests. Jay On 3/11/12, Eli Barzilay e...@barzilay.org wrote: Two days ago, Jay McCarthy wrote: [...] I've expanded 'raco test' to support running a different submodule or running the default module (what's a good name for it?) if the submodule isn't there. I intend to change DrDr so that it always uses raco test -r rather than racket -t. Two comments on this: 1. I still would like to see a way to properly run some submodule other than `main' that is not tied to a raco test. But probably a better place for this is a new command-line flag for the main `racket' executable, where the default for the flag would be `main'. (This should probably use the same terminology as `slice', or anything else if it changes.) Then, `raco test' could be explained as doing two things: changing the default to `test'[*], and running it recursively over a bunch of files (which is definitely suitable for testing but not for other modes). ([*]I still prefer `tests' but...) 2. It sounds dangerous to encourage using this by making drdr do it. The thing is that while the tests don't have a loading overhead, they will still add dependencies to the files. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Submodules dependencies
Just now, Jay McCarthy wrote: I agree with your point #1 heartily. I don't follow point #2. Do you mean that currently by having two files the tests can depend on things that the code does not (for purposes of distribution, etc) and having those tests embedded in the files increases the cross-collection dependencies as well as increasing compilation time? I suppose that is true, but I don't know how severe it is and I value having the tests. Say that the `foo' collection author sees that and thinks ooh, a useful feature, then folds the tests into the main code -- so foo/bar.rkt has some library code as well as a `test' submodule that uses `tests/eli-tester'. The collection becomes undistributable because `tests/*' is not distributed. Variations: using `rackunit' makes all of `foo' depend on rackunit, a dependency that is needed only for tests, putting the scribble docs in the same file leads to a dependency on scribble, etc. [I guess that it could be argued that all of these dependencies are justified, by my own argument is a proxy argument: linux distributions usually have different sub-packages for docs and for developement files (= tests), and I think that enough thought has been spent there on deciding that this is a useful way to divide things. On one hand, I choose to shoot for a distro-friendly packaging, which is why I take this argument as valid without questioning it. On the other hand, as someone who appreciates such division when I install other packages, I *definitely* see the value in having it -- I imagine some random application that is written in ruby/python/whatever, and I'd hesitate to install it if it pulls in some IDE package, a documentation system, and test files.] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
Two days ago, Matthew Flatt wrote: I don't think that explicit `module' or `module*' forms will be that common. Instead, I expect that they'll mostly be generated by macros, such as a `main' macro or Jay's `define-test' macro. But if they become common, or if we often want to re-export an external module via a submodule, then we should revisit this point. Sounds to me like `module' can be common enough for segregating some code, possibly even in a different language. Something like a bit of lazy/eager code inside an otherwise eager/lazy module, or some well-isolated part of the code that uses unsafe operators, etc. Just like with the case for separate files. As for which one is more natural, I think that the main point is to consider the dependencies: whether it more natural to expect that a submodule depends on its surrounding module or the other way. Currently, it's sub-`module*' ⇢ module ⇢ sub-`module' I think that the #f-as-the-initial-require thing being allowed in `module*' is made clear by this picture, and also the similarity between module toplevel sub-`module' on one hand, and repl module on the other. (In case it's not clear: I'm not complaining on anything -- I'm just providing further explanation that I think justifies the current names for the two forms.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
Yesterday, Matthew Flatt wrote: At Fri, 9 Mar 2012 16:35:25 -0500, Eli Barzilay wrote: (require (submod 'zoo monkey-house)) [...] a shorthand for `(submod . zoo)' [...] ...especially here -- why is there a quote only on the first and not on the second? That jumped out at me, too. But the first is a module path and the second is a submodule name. For example, (submod zoo monkey-house) would mean the `monkey-house' submodule of main.rkt from the zoo collection, not a `monkey-house' subsubmodule in a `zoo' submodule. Ah, it wasn't clear that `submod' can access submodules in other modules. (This raises another issue which I'll continue below.) In any case, that quote still bugs me... It makes more sense to me to require quotes on all of the submodule parts, but that looks worse. Maybe the problem is that it looks like the syntax is (submod X ...) for equal Xs, but it's really (submod X Y ...). This suggests a solution that makes the above (submod zoo monkey-house) less convenient (and I expect it to be fairly uncommon--?) -- something like (submod (real-module zoo) monkey-house) Can something like that work out better? (With some proper name instead of `real-module', of course.) Is there any meaning for (submod foo) without the quote (or a sting)? We could allow (submod foo) as equivalent to foo that is, as a reference to `foo' with an empty submodule path. This seems like a sensible thing to do, given my current understanding. Perhaps a more obvious question is why aren't all `submod' uses get . as an implicit first expression? I don't see how lets you reach a submodule from the top level or from within a different top-level module. So, this is the bit that wasn't clear to me in your original email. I now see that this code works: | #lang racket/load | | (module my-code racket/base | (module private racket/base | (provide secret) | (define secret 1)) | (require 'private) | (provide public) | (define public (list secret))) | | (module hacker racket/base | (require (submod 'my-code private)) | (printf The secret is ~a\n secret)) | | (require 'hacker) Isn't this kind of code something that doesn't have a real use, perhaps other than some reflection stuff (like repl uses)? I first thought that the whole point of allowing a sub-`module' would be to have some otherwise-inaccessible private code in it (as the fictitious author of that `my-code' module thinks). If that's wasn't possible, or possible only as a some semi-obscure-reflection-api then the `submod' syntax could be simpler. I also love the analogy to paths -- but using strings for them doesn't look so nice, since strings are begging to be combined... (I can already see myself wishing for ./../foo.) Other than the obvious reader issue, would there be a problem in using `|.|' and `..' for these (and making them into special module names)? Submodule identifiers are not currently constrained, and I think we should avoid constraining them. If we refrain from constraining submodule names, then `..' could be the name of a submodule. It just seems similar to the old (lib.ss some path) thing in that it's asking to be changed to something that is easier to remember. Maybe make .. have an implicit . before it so there's no need for a mysterious `. ..'? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
At Wed, 7 Mar 2012 10:14:35 -0700, Matthew Flatt wrote: I've added submodules to a version of Racket labeled v5.2.900.1 Submodules are now pushed to the Racket git repo. I haven't yet added a syntactic form to simplify (module* main #f ) My first idea was `main', as in (main ) but that seems too quiet and likely to create collisions. (It does create a collision in part of the contract library, which imports `racket/base' for syntax and defines a for-syntax `main' function.) Jon suggests `submodule': (submodule main ...) This suggestion has the advantage of replacing all `(module* #f )' combinations, and mostly I like this direction. However, `submodule' would be only one way to define a submodule, while `submod' in a module path corresponds to submodule in the more general sense. It could be that `submodule' is on the right path and other terminology should change, or maybe there's a more specific word to use for a `(module* #f )' replacement instead of `submodule'. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
I'll pushed an improved version of the test macro shortly. Jay On Fri, Mar 9, 2012 at 11:04 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 7 Mar 2012 10:14:35 -0700, Matthew Flatt wrote: I've added submodules to a version of Racket labeled v5.2.900.1 Submodules are now pushed to the Racket git repo. I haven't yet added a syntactic form to simplify (module* main #f ) My first idea was `main', as in (main ) but that seems too quiet and likely to create collisions. (It does create a collision in part of the contract library, which imports `racket/base' for syntax and defines a for-syntax `main' function.) Jon suggests `submodule': (submodule main ...) This suggestion has the advantage of replacing all `(module* #f )' combinations, and mostly I like this direction. However, `submodule' would be only one way to define a submodule, while `submod' in a module path corresponds to submodule in the more general sense. It could be that `submodule' is on the right path and other terminology should change, or maybe there's a more specific word to use for a `(module* #f )' replacement instead of `submodule'. _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
[Some of these points may have come up earlier, I just didn't want to lose comments so reply as I read it.] [To be clear in advance, the following should be qualified by an I love it.] Two days ago, Matthew Flatt wrote: Given the term submodule, the first thing that you're likely to try will work as expected: #lang racket/base (module zoo racket/base (provide tiger) (define tiger Tony)) (require 'zoo) tiger Within `module', a module path of the form `(quote id)' refers to the submodule `id', if any. If there's no such submodule, then `(quote id)' refers to an interactively declared module, as before. This is *really* nice in how it's building a scope for module names, but OTOH, it makes the quote seem more like a syntactic hack... [...later...] (require (submod 'zoo monkey-house)) [...] a shorthand for `(submod . zoo)' [...] ...especially here -- why is there a quote only on the first and not on the second? Is there any meaning for (submod foo) without the quote (or a sting)? If not, then having (submod zoo monkey-house) seems beter in building up an intuition of `submod' implicitly quoting the following name. Perhaps a more obvious question is why aren't all `submod' uses get . as an implicit first expression? IIUC, this means that it works nicely without quotes, and there's only a single magical .. thing. The 'zoo module path above is really a shorthand for `(submod . zoo)', where . means the enclosing module and `zoo' is its submodule. You could write `(submod . zoo monkey-house)' in place of `(submod 'zoo monkey-house)'. I also love the analogy to paths -- but using strings for them doesn't look so nice, since strings are begging to be combined... (I can already see myself wishing for ./../foo.) Other than the obvious reader issue, would there be a problem in using `|.|' and `..' for these (and making them into special module names)? Or if there was always an implicit first ., then there's only need for a single `..' magic token thing... (It even makes syntactic sense that (submod) is something that you can't require.) Reading the later Design Issues section, I see that these are indeed arbitrary. So to clarify, I propose a `submod' form that always begins with a . (under its current semantics), with no need to use a quote, and with `..' being a special name that goes up the hierarchy. To make things connect nicely to toplevel requires, (submod foo) could also resort to the repl-entered module thing, which means that we now have: (require (submod foo)) is very common, so it can be written a bit more conveniently as (require 'foo) (But this might be pushing the description into showing them as closer than they are.) Instead of `require'ing its enclosing module, a `module*' form can use `#f' as its language, in which case its lexical context starts with all of the bindings of the enclosing module (implicitly imported) instead of with an empty lexical context. As a result, the submodule can access bindings of the enclosing module that are not exported: #lang racket/base (module aquarium racket/base (define fish '(1 2)) (module* book #f (append fish '(red blue (require (submod 'aquarium book)) The explanation for this looks reasonable, but the result looks unfortunate since the common case requires you to remember to add two special things (the `*' and `#f'). But I also really don't like to abuse `module' for both uses. How about just (submodule foo ...) be a more memorable syntax for (module* foo #f ...)? Later, I see: As things stand, the ugly pattern `(module* main #f ...)' would be common. Probably we should have a macro that expands to `(module* main #f ...)'. Should the macro be called `main'? So above is my suggestion. But maybe even make it more generally convenient so it can cover the `test' use without needing a library -- taking what Jay did (I think, didn't look at the code or the followups, yet), and making this: (submodule name E ...) be something that can appear anywhere in the code, expands to what (module* main #f E ...) is doing now, *and* is allowed to be used more than once, with all uses being collected into a single submodule. This way I can easily interleave regular code, main code, test code, sanity assertion code, documentation code etc. IOW, I see this as something that can be used straightforwardly with any testing tool, or made into a macro by one, or being used in the obvious way by in-line documentation tools like Neil V's mcfly thing (which is more straightforward for this than srcdoc). A common use of `module*' is likely to be with `main', since `racket' will load a `main' submodule (after `require'ing its enclosing module) for a module named on its command line. For example, if you run this program via `racket': #lang racket/base (provide fish) (define fish '(1 2)) (Just in case this was missed and
Re: [racket-dev] submodules
I just pushed... - module** Like module* but combines multiple occurrences of the same submodule name into one module* - when-testing An abbreviation of module** with the name test and the #f language - raco test Finds all the files in a directory and requires their test module I like the name 'raco test'; I'm meh on 'when-testing', I didn't want to clash with eli-tester/test or something, but I think whatever we go with (and I think there should be such a convenience macro) should be similar to what happens with main; I don't know a better name for module**. I thought of something using an @ to suggest the splicing, but didn't like anything when I tried it. Jay On Fri, Mar 9, 2012 at 11:56 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I'll pushed an improved version of the test macro shortly. Jay On Fri, Mar 9, 2012 at 11:04 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 7 Mar 2012 10:14:35 -0700, Matthew Flatt wrote: I've added submodules to a version of Racket labeled v5.2.900.1 Submodules are now pushed to the Racket git repo. I haven't yet added a syntactic form to simplify (module* main #f ) My first idea was `main', as in (main ) but that seems too quiet and likely to create collisions. (It does create a collision in part of the contract library, which imports `racket/base' for syntax and defines a for-syntax `main' function.) Jon suggests `submodule': (submodule main ...) This suggestion has the advantage of replacing all `(module* #f )' combinations, and mostly I like this direction. However, `submodule' would be only one way to define a submodule, while `submod' in a module path corresponds to submodule in the more general sense. It could be that `submodule' is on the right path and other terminology should change, or maybe there's a more specific word to use for a `(module* #f )' replacement instead of `submodule'. _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
On Fri, Mar 9, 2012 at 5:58 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I just pushed... - module** Like module* but combines multiple occurrences of the same submodule name into one module* - when-testing An abbreviation of module** with the name test and the #f language - raco test Finds all the files in a directory and requires their test module I like the name 'raco test'; I'm meh on 'when-testing', I didn't want to clash with eli-tester/test or something, but I think whatever we go with (and I think there should be such a convenience macro) should be similar to what happens with main; I don't know a better name for module**. I thought of something using an @ to suggest the splicing, but didn't like anything when I tried it. How about begin-for-testing? And extend-submodule? --Carl _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
Just now, Jay McCarthy wrote: I just pushed... - module** Like module* but combines multiple occurrences of the same submodule name into one module* But... it adds more stars... I don't think that there's any need for a convenience macro that does just the combining, since that feature is for macro writers anyway. Here's what I have in mind: (sub main (printf Welcome to MY library!\n)) (sub tests (require tests/eli-tester) (printf Testing...)) (define (plus x y) (+ x y)) (sub tests (printf ~s\n shuffle)) (sub main (printf Running tests...\n) (require 'tests) (printf Goodbye.\n)) I have it almost working -- I just have one problem left (that last nested require doesn't work). - when-testing An abbreviation of module** with the name test and the #f language (... As I wrote the above, I realized that `tests' is a better name for this.) In any case, I think that the above is lightweight enough that there is no need for any `when-something'. (I dislike specific names because there's more than just testing.) - raco test Finds all the files in a directory and requires their test module (And it works for the specified path(s) if given?) How about generalizing this too? Something like raco run tests path/s This way, you get the others for free since `tests' is not hard wired: raco run extensive-tests path/s raco run docs path/s ... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
A few minutes ago, Eli Barzilay wrote: [...] Here's what I have in mind: (Other things were broken there...) Here's the code that works now: (sub tests (require tests/eli-tester)) ; make it known before main (sub main (printf Welcome to MY library!\n)) (define (plus x y) (+ x y)) (sub tests (test (plus 1 2) = 3)) (sub main (require (submod . .. tests)) (printf Goodbye.\n)) There is the obvious output order here where there main printouts come after the test message because `tests' is instantiated before the printout forms in `main'. If the test is changed to a failure, it throws an error and you won't see that printout. Complete code below, with the same example done with rackunit. --- #lang racket/base (require (for-syntax racket/base)) (define-for-syntax subs '()) (define-syntax (sub stx) (syntax-case stx () [(_ name E ...) (identifier? #'name) (let ([sub (assq (syntax-e #'name) subs)]) (if sub (begin ((cdr sub) #'(begin E ...)) #'(begin)) (with-syntax ([(submod) (generate-temporaries #'(name))]) (let ([bodies (list (syntax-local-introduce #'(begin E ...)))]) (set! subs (cons (cons (syntax-e #'name) (case-lambda [(E) (set! bodies (cons E bodies))] [() (reverse bodies)])) subs))) (syntax-local-lift-module-end-declaration #'(submod)) #'(define-syntax (submod stx) (with-syntax ([(E* (... ...)) ((cdr (assq 'name subs)))]) (syntax-local-introduce #'(module* name #f E* (... ...])) (sub tests (require rackunit)) ; make it known before main (sub main (printf Welcome to MY library!\n)) (define (plus x y) (+ x y)) (sub tests (check-equal? (plus 1 2) 3) (check-equal? (plus 1 2) 33)) (sub main (require (submod . .. tests)) (printf Goodbye.\n)) --- -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
At Fri, 9 Mar 2012 15:58:11 -0700, Jay McCarthy wrote: I just pushed... - module** Like module* but combines multiple occurrences of the same submodule name into one module* I like this direction --- and like everyone, I wish for a better name. I don't like `submodule' or `sub' for this, because it's a particular way of creating submodules, not a general form for submodules. How about `facet', with the terminology that facets are implemented as submodules? For example, a module with a `main' facet could be #lang racket/base (facet main (require racket/cmdline) (command-line .)) but you could also use `(facet main )' multiple times to add parts to the `main' submodule. - when-testing An abbreviation of module** with the name test and the #f language I agree with Eli that if we have a good replacement for `submodule**', then we may not need this one. For example, I like (facet test ) better than (when-testing ) - raco test Finds all the files in a directory and requires their test module Good! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
I'll reply to the rest later, but two quick ones: Just now, Matthew Flatt wrote: How about just (submodule foo ...) be a more memorable syntax for (module* foo #f ...)? That was Jon's suggestion, and my objection is that submodule means something more general than those nested modules that are declared with `submodule'. I just realized that the main use of this (the specific combination of `module*' with #f) is for sectioning the file -- so how about going in the direction of `subsection', or to avoid the obvious problem with scribble: `subpart'? (BTW, there's an obvious question here of why not do that for all paths, so that `foo/bar/baz' can access a `bar/baz' submodule in `foo' or a `baz' in `foo/bar'... Search paths cause lots of trouble and should be avoided when possible. This particular two-step search seem to be just barely tolerable for `#lang', and I still worry about it; I wouldn't suggest it if I saw a better way to accommodate existing code. I completely agree -- specifically, the mess that I referred to at the end of that comment was due to how things ended: I inevitably would resort to grepping text to find where some change needs to be made, I created code mostly via copy-paste, and macros would get very confusing to deal with. It was a kind of an experiment that demonstrated why this particular generalization looks really cute on paper, but in practice it is a total failure. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
On Fri, Mar 9, 2012 at 9:54 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I intend to change DrDr so that it always uses raco test -r rather than racket -t. I assume you mean just changing the defaults. Will this resulting in running any less code? -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
Yes, just changing the default. raco test -r will behave like racket -t unless there is a test submodule, in which case, it will actually run the tests. Jay On Fri, Mar 9, 2012 at 10:04 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Fri, Mar 9, 2012 at 9:54 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I intend to change DrDr so that it always uses raco test -r rather than racket -t. I assume you mean just changing the defaults. Will this resulting in running any less code? -- sam th sa...@ccs.neu.edu -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
I've made a test collecting macro. https://gist.github.com/2003201 test.rkt gives you 'define-test' (define-test id e ...) will create a module named 'test' that can see you local bindings (like module* #f) at the end of the module that contains all the code in e In addition, you get the (id e ...) form that adds the given expressions to the test module. I expect most uses will look like: (require racket/test) (define-test test (require rackunit)) (define f ...) (test ... f tests ...) (define g ...) (test ... g tests ...) Jay On Wed, Mar 7, 2012 at 12:07 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I love it---especially for the test collecting macro. I will try to write it and report back. Jay On Wed, Mar 7, 2012 at 10:14 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I've added submodules to a version of Racket labeled v5.2.900.1 that's here: https://github.com/mflatt/submodules After we've sorted out any controversial parts of the design and after the documentation is complete, then I'll be ready to merge to the main Racket repo. Why Submodules? --- Using submodules, you can abstract (via macros) over a set of modules that have distinct dynamic extents and/or bytecode load times. You can also get a private communication channel (via binding) from a module to its submodules. Some uses: * When you run a module via `racket', if it has a `main' submodule, then the `main' module is instantiated --- but not the `main' submodules of any other modules used by the starting module. This protocol is implemented for `racket', but not yet for DrRacket. * Languages with separate read-time, configure-time, and run-time code can be defined in a single module, with the configure-time and read-time code in submodules. * A testing macro could collect test cases and put them into a separate `test' submodule', so that testing code is not run or even loaded when the module is used normally. * An improved `scribble/srcdoc' can expose documentation through a submodule instead of through re-expansion hacks. * If you want to export certain of a module's bindings only to when explicitly requested (i.e., not when the module is `require'd normally), you can export the bindings from a submodule, instead. When I first started talking about these problems last summer, I called the solution sketch facets or modulets, but the design has evolved into submodules. Nesting `module' Given the term submodule, the first thing that you're likely to try will work as expected: #lang racket/base (module zoo racket/base (provide tiger) (define tiger Tony)) (require 'zoo) tiger Within `module', a module path of the form `(quote id)' refers to the submodule `id', if any. If there's no such submodule, then `(quote id)' refers to an interactively declared module, as before. Submodules can be nested. To access a submodule from outside the enclosing module, use the `submod' module path form: #lang racket/base (module zoo racket/base (module monkey-house racket/base (provide monkey) (define monkey Curious George)) (displayln Ticket, please)) (require (submod 'zoo monkey-house)) monkey The 'zoo module path above is really a shorthand for `(submod . zoo)', where . means the enclosing module and `zoo' is its submodule. You could write `(submod . zoo monkey-house)' in place of `(submod 'zoo monkey-house)'. Note that `zoo' and `monkey-house' are not bound as identifiers in the module above --- just like `module' doesn't add any top-level bindings. The namespace of modules remains separate from the namespace of variables and syntax. Along those lines, submodules are not explicitly exported, because they are implicitly public. When you run the above program, Ticket, please is *not* displayed. Unless a module `require's a submodule, instantiating the module does not instantiate the submodule. Similarly, instantiating a submodule does not imply instantiating its enclosing module. Furthermore, if you compile the above example to bytecode and run it, the bytecode for `zoo' is not loaded. Only the bytecode for the top-level module and `monkey-house' is loaded. Nesting `module*' - Submodules declared with `module' are declared locally while expanding a module body, which means that the submodules can be `require'd afterward by the enclosing module. This ordering means, however, that the submodule cannot `require' the enclosing module. The submodule also sees no bindings of the enclosing module; it starts with an empty lexical context. The `module*' form is like `module', but it can be used only for submodules, and it defers the submodule's expansion until after the enclosing module is otherwise expanded. As a result, a submodule using `module*' can `require' its enclosing module, while the enclosing module cannot require
Re: [racket-dev] submodules
One more thing, I anticipate that the 'main' module in my test.rkt will be raco test and I would extend it to allow you to give a directory that it will require (if present) all the test modules. You could also have Test button in DrRacket. Jay On Thu, Mar 8, 2012 at 1:29 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I've made a test collecting macro. https://gist.github.com/2003201 test.rkt gives you 'define-test' (define-test id e ...) will create a module named 'test' that can see you local bindings (like module* #f) at the end of the module that contains all the code in e In addition, you get the (id e ...) form that adds the given expressions to the test module. I expect most uses will look like: (require racket/test) (define-test test (require rackunit)) (define f ...) (test ... f tests ...) (define g ...) (test ... g tests ...) Jay On Wed, Mar 7, 2012 at 12:07 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I love it---especially for the test collecting macro. I will try to write it and report back. Jay On Wed, Mar 7, 2012 at 10:14 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I've added submodules to a version of Racket labeled v5.2.900.1 that's here: https://github.com/mflatt/submodules After we've sorted out any controversial parts of the design and after the documentation is complete, then I'll be ready to merge to the main Racket repo. Why Submodules? --- Using submodules, you can abstract (via macros) over a set of modules that have distinct dynamic extents and/or bytecode load times. You can also get a private communication channel (via binding) from a module to its submodules. Some uses: * When you run a module via `racket', if it has a `main' submodule, then the `main' module is instantiated --- but not the `main' submodules of any other modules used by the starting module. This protocol is implemented for `racket', but not yet for DrRacket. * Languages with separate read-time, configure-time, and run-time code can be defined in a single module, with the configure-time and read-time code in submodules. * A testing macro could collect test cases and put them into a separate `test' submodule', so that testing code is not run or even loaded when the module is used normally. * An improved `scribble/srcdoc' can expose documentation through a submodule instead of through re-expansion hacks. * If you want to export certain of a module's bindings only to when explicitly requested (i.e., not when the module is `require'd normally), you can export the bindings from a submodule, instead. When I first started talking about these problems last summer, I called the solution sketch facets or modulets, but the design has evolved into submodules. Nesting `module' Given the term submodule, the first thing that you're likely to try will work as expected: #lang racket/base (module zoo racket/base (provide tiger) (define tiger Tony)) (require 'zoo) tiger Within `module', a module path of the form `(quote id)' refers to the submodule `id', if any. If there's no such submodule, then `(quote id)' refers to an interactively declared module, as before. Submodules can be nested. To access a submodule from outside the enclosing module, use the `submod' module path form: #lang racket/base (module zoo racket/base (module monkey-house racket/base (provide monkey) (define monkey Curious George)) (displayln Ticket, please)) (require (submod 'zoo monkey-house)) monkey The 'zoo module path above is really a shorthand for `(submod . zoo)', where . means the enclosing module and `zoo' is its submodule. You could write `(submod . zoo monkey-house)' in place of `(submod 'zoo monkey-house)'. Note that `zoo' and `monkey-house' are not bound as identifiers in the module above --- just like `module' doesn't add any top-level bindings. The namespace of modules remains separate from the namespace of variables and syntax. Along those lines, submodules are not explicitly exported, because they are implicitly public. When you run the above program, Ticket, please is *not* displayed. Unless a module `require's a submodule, instantiating the module does not instantiate the submodule. Similarly, instantiating a submodule does not imply instantiating its enclosing module. Furthermore, if you compile the above example to bytecode and run it, the bytecode for `zoo' is not loaded. Only the bytecode for the top-level module and `monkey-house' is loaded. Nesting `module*' - Submodules declared with `module' are declared locally while expanding a module body, which means that the submodules can be `require'd afterward by the enclosing module. This ordering means, however, that the submodule cannot `require' the enclosing module. The submodule also sees no bindings of the enclosing
Re: [racket-dev] submodules
This sounds great! I haven't tried it out yet, but here are some preliminary comments. On 2012-03-07 10:14:35 -0700, Matthew Flatt wrote: Submodules declared with `module' are declared locally while expanding a module body, which means that the submodules can be `require'd afterward by the enclosing module. This ordering means, however, that the submodule cannot `require' the enclosing module. [...] The `module*' form is like `module', but it can be used only for submodules, and it defers the submodule's expansion until after the enclosing module is otherwise expanded. As a result, a submodule using `module*' can `require' its enclosing module, while the enclosing module cannot require the submodule. It seems to me that `module*` maybe actually be the common case for submodules because most of the time I would expect that you want to use the bindings of the enclosing module. This seems true for unit tests, driver modules, documentation (requiring for-template), and so on. Would it make sense to swap the `module` and `module*` forms? *** Another aspect of the syntax that I foresee being annoying is that each module nesting adds an additional indentation level. On the other hand, I don't see any good alternative for this. I only bring this up because this was problematic enough in the past to invent the #lang shorthand. Maybe a pattern that could avoid this is to have something like #lang racket/main #:main driver.rkt #:tests tests.rkt which would bring in the given modules (in the filesystem) as submodules. That way you could define submodules separately but still package them together in order to follow any protocols for documentation or unit testing that come about with submodules. Is that implementable with submodules? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
On Thu, Mar 8, 2012 at 1:41 PM, Asumu Takikawa as...@ccs.neu.edu wrote: Maybe a pattern that could avoid this is to have something like #lang racket/main #:main driver.rkt #:tests tests.rkt which would bring in the given modules (in the filesystem) as submodules. That way you could define submodules separately but still package them together in order to follow any protocols for documentation or unit testing that come about with submodules. Is that implementable with submodules? Yes. I just tested this idea. You could expand to: include.rkt: #lang racket/base (define (f x) 1) (module* test #f (require racket/include) (include include-tests.rkt)) include-tests.rkt: (require rackunit) (check-equal? (f 1) 1) (check-equal? (f 3) 2) Although I personally don't like it as much :) Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
At Thu, 8 Mar 2012 15:41:38 -0500, Asumu Takikawa wrote: This sounds great! I haven't tried it out yet, but here are some preliminary comments. On 2012-03-07 10:14:35 -0700, Matthew Flatt wrote: Submodules declared with `module' are declared locally while expanding a module body, which means that the submodules can be `require'd afterward by the enclosing module. This ordering means, however, that the submodule cannot `require' the enclosing module. [...] The `module*' form is like `module', but it can be used only for submodules, and it defers the submodule's expansion until after the enclosing module is otherwise expanded. As a result, a submodule using `module*' can `require' its enclosing module, while the enclosing module cannot require the submodule. It seems to me that `module*` maybe actually be the common case for submodules because most of the time I would expect that you want to use the bindings of the enclosing module. This seems true for unit tests, driver modules, documentation (requiring for-template), and so on. Would it make sense to swap the `module` and `module*` forms? That's how it was at first, but I didn't like how (module m racket/base) (require 'm) was completely different at the top level and within a module. Although the correspondence between `module' at the top level and within a `module' is only approximate, it makes things much easier to explain. It's also easier to explain that `#f' is allowed as the language of a `module*', which is always a submodule, and `#f' is never allowed as the language of `module'. (In fact, there was no nested `module' until the last few hours before my post. I had `module*' as `module', and it was starting to look difficult to explain... Realizing that nearly everything was in place to support nested `module' in addition to `module*' was my biggest aha! moment.) Another aspect of the syntax that I foresee being annoying is that each module nesting adds an additional indentation level. On the other hand, I don't see any good alternative for this. I only bring this up because this was problematic enough in the past to invent the #lang shorthand. I don't think that explicit `module' or `module*' forms will be that common. Instead, I expect that they'll mostly be generated by macros, such as a `main' macro or Jay's `define-test' macro. But if they become common, or if we often want to re-export an external module via a submodule, then we should revisit this point. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
Nice -- just what I wished for last spring. -- Matthias On Mar 8, 2012, at 3:39 PM, Jay McCarthy wrote: One more thing, I anticipate that the 'main' module in my test.rkt will be raco test and I would extend it to allow you to give a directory that it will require (if present) all the test modules. You could also have Test button in DrRacket. Jay On Thu, Mar 8, 2012 at 1:29 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I've made a test collecting macro. https://gist.github.com/2003201 test.rkt gives you 'define-test' (define-test id e ...) will create a module named 'test' that can see you local bindings (like module* #f) at the end of the module that contains all the code in e In addition, you get the (id e ...) form that adds the given expressions to the test module. I expect most uses will look like: (require racket/test) (define-test test (require rackunit)) (define f ...) (test ... f tests ...) (define g ...) (test ... g tests ...) Jay On Wed, Mar 7, 2012 at 12:07 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I love it---especially for the test collecting macro. I will try to write it and report back. Jay On Wed, Mar 7, 2012 at 10:14 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I've added submodules to a version of Racket labeled v5.2.900.1 that's here: https://github.com/mflatt/submodules After we've sorted out any controversial parts of the design and after the documentation is complete, then I'll be ready to merge to the main Racket repo. Why Submodules? --- Using submodules, you can abstract (via macros) over a set of modules that have distinct dynamic extents and/or bytecode load times. You can also get a private communication channel (via binding) from a module to its submodules. Some uses: * When you run a module via `racket', if it has a `main' submodule, then the `main' module is instantiated --- but not the `main' submodules of any other modules used by the starting module. This protocol is implemented for `racket', but not yet for DrRacket. * Languages with separate read-time, configure-time, and run-time code can be defined in a single module, with the configure-time and read-time code in submodules. * A testing macro could collect test cases and put them into a separate `test' submodule', so that testing code is not run or even loaded when the module is used normally. * An improved `scribble/srcdoc' can expose documentation through a submodule instead of through re-expansion hacks. * If you want to export certain of a module's bindings only to when explicitly requested (i.e., not when the module is `require'd normally), you can export the bindings from a submodule, instead. When I first started talking about these problems last summer, I called the solution sketch facets or modulets, but the design has evolved into submodules. Nesting `module' Given the term submodule, the first thing that you're likely to try will work as expected: #lang racket/base (module zoo racket/base (provide tiger) (define tiger Tony)) (require 'zoo) tiger Within `module', a module path of the form `(quote id)' refers to the submodule `id', if any. If there's no such submodule, then `(quote id)' refers to an interactively declared module, as before. Submodules can be nested. To access a submodule from outside the enclosing module, use the `submod' module path form: #lang racket/base (module zoo racket/base (module monkey-house racket/base (provide monkey) (define monkey Curious George)) (displayln Ticket, please)) (require (submod 'zoo monkey-house)) monkey The 'zoo module path above is really a shorthand for `(submod . zoo)', where . means the enclosing module and `zoo' is its submodule. You could write `(submod . zoo monkey-house)' in place of `(submod 'zoo monkey-house)'. Note that `zoo' and `monkey-house' are not bound as identifiers in the module above --- just like `module' doesn't add any top-level bindings. The namespace of modules remains separate from the namespace of variables and syntax. Along those lines, submodules are not explicitly exported, because they are implicitly public. When you run the above program, Ticket, please is *not* displayed. Unless a module `require's a submodule, instantiating the module does not instantiate the submodule. Similarly, instantiating a submodule does not imply instantiating its enclosing module. Furthermore, if you compile the above example to bytecode and run it, the bytecode for `zoo' is not loaded. Only the bytecode for the top-level module and `monkey-house' is loaded. Nesting `module*' - Submodules declared with `module' are declared locally while expanding a module body, which means that the submodules can be `require'd afterward by the
