[racket-dev] Submodules & dependencies

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Mon Mar 12 15:13:54 EDT 2012

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 <mflatt at 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
>> > <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


Posted on the dev mailing list.