[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
> > <matthias at 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
> >>> <matthias at 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 <matthias at 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
> >>>>>>> <matthias at 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 <jay at 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 <jay at 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