[racket-dev] Submodules & dependencies

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
>