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
