[racket-dev] Submodules & dependencies

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