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" - D&C 93 >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Jay McCarthy <j...@cs.byu.edu> >> >>>>> Assistant Professor / Brigham Young University >> >>>>> http://faculty.cs.byu.edu/~jay >> >>>>> >> >>>>> "The glory of God is Intelligence" - D&C 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
