[racket-dev] Submodules & dependencies

I think Jay is expressing an Eli-concern: we need to distribute 
the full source to determine whether something can be thrown away. 


On Mar 12, 2012, at 3:13 PM, Robby Findler wrote:

> 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