[racket-dev] Submodules & dependencies

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

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
>


Posted on the dev mailing list.