[racket-dev] Submodules & dependencies

I agree with Robby.

Jay

On Mon, Mar 12, 2012 at 1:18 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> I thought Matthew was pointing out how we can distribute some source
> that works if you set a parameter properly and that same source will
> contain no test-based dependencies.
>
> Boy, this conversation sure makes me wish for the ability to just
> gather everyone up around a whiteboard or something :(
>
> Robby
>
> On Mon, Mar 12, 2012 at 2:15 PM, Matthias Felleisen
> <matthias at ccs.neu.edu> wrote:
>>
>> 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
>>
>
> _________________________
>  Racket Developers list:
>  http://lists.racket-lang.org/dev



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