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
