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
