[plt-scheme] Why Modules?

Always use modules.

If you also need mutual recursion, use units too

-- Matthias



On Nov 22, 2008, at 10:53 AM, Eric Tanter wrote:

> I'm glad this issue of module vs. unit pops up again, because I'm  
> still not sure about when to use what.
>
> From the different responses here, I gather that if there is some  
> syntactic extensions involved, modules are the way to go (at least  
> for now). Is this right?
>
> In a problem I exposed on the list some months ago, I had problems  
> with modules which were unrelated to needing syntactic extensions.  
> It also did not have to do with extreme separation of interface/ 
> implementation that Matthew is refering to.
>
> To recall, I just wanted to structure plain code nicer in order to  
> be able to use the IDE tools (like module browser and multi-file  
> debugging). But I ran into the limitation of not being able to  
> define mutually recursive modules. Some people then suggested  
> basically bootstrapping the recursion by hand (with explicit side  
> effects), which I must say, although it works, seems rather dirty/ 
> ad-hoc to me. I also played with dynamic-require but then the  
> debugging looped for ever or did not work.
>
> So I'm still puzzled about whether I should go for unit or keep to  
> modules. As of now, since time was pressing (deadline), I finally  
> just stayed with a plain multi-file/load configuration -- with poor  
> IDE support.
>
> Thanks for helping!
>
> -- Éric
>
>
> On Nov 21, 2008, at 12:53 , Matthias Felleisen wrote:
>
>>
>> P.S. One other point to note is that people often ask for contracts
>> for unit boundaries because the module boundaries come with it.
>> Stevie Strickland has just started working on the proper integration
>> of units and contracts, as a step toward typed units. -- Matthias
>>
>>
>>
>> On Nov 21, 2008, at 10:47 AM, Matthew Flatt wrote:
>>
>>> At Thu, 20 Nov 2008 20:57:51 -0500, "Ittai Balaban" wrote:
>>>> In many respects (syntax bindings not included), units provide a  
>>>> much
>>>> richer framework than modules - the latter cannot be assembled
>>>> compositionally, prohibit cyclic dependencies, and do not allow  
>>>> multiple
>>>> instantiations. Thus, my question is, since you make such a  
>>>> convincing
>>>> case for units in the '99 paper, why did PLT find it necessary to
>>>> introduce a new abstraction in the form of modules? Did you run  
>>>> into some
>>>> intrinsic limitations of units?
>>>
>>> The continuation of that work is Scott Owens's dissertation
>>>
>>>  http://www.cs.utah.edu/plt/publications/owens-phd.pdf
>>>
>>> and related papers
>>>
>>>  From Structures and Functors to Modules and Units
>>>  ICFP 2006 Owens and Flatt
>>>  http://www.cs.utah.edu/plt/publications/icfp06-of.pdf
>>>
>>>
>>>  Syntactic Abstraction in Component Interfaces
>>>  GPCE 2005 Culpepper, Owens, and Flatt.
>>>  http://www.cs.utah.edu/plt/publications/gpce05-cof.pdf
>>>
>>> about the interplay of modules and units.
>>>
>>>
>>> As you and others noted, we introduced `module' to deal with  
>>> syntactic
>>> extension. Another explanation is that you need some sort of module
>>> system to host a unit system: to create a unit that uses AN
>>> implementation of an interface, you need some way to refer to THE
>>> specification of the interface, as well as a way to refer to  
>>> specific
>>> implementations to link them together.
>>>
>>> At the same time, the module system is weaker than a unit system for
>>> composing systems, and we really should be putting our libraries  
>>> into
>>> units (i.e., I still believe most of the original `unit'  
>>> motivation).
>>> The reason we don't, though, is the same reason that ML programmers
>>> don't write "fully functorized" code: it's a bit of a pain to split
>>> implementation from interface and to explicitly link  
>>> implementations,
>>> and the resulting extra flexibility is needed so rarely that the  
>>> pain
>>> doesn't seem worthwhile --- unless we really need the  
>>> flexibility, in
>>> which case we do use units.
>>>
>>> We've attacked the "bit of a pain" problem using syntactic  
>>> extension.
>>> With `#lang unit' and `define-compound-unit/infer', we've removed  
>>> some
>>> tedious syntax and bookkeeping for using units. It will take more  
>>> work
>>> in that direction, though, to make it as easy as throwing a module
>>> together. Possibly we just need to be more disciplined. Also, it  
>>> would
>>> take more compiler work to get back the current level of performance
>>> for cross-module calls (e.g., if `+' were imported through a  
>>> unit, then
>>> "just in time" would have to be later than it is currently).
>>>
>>>
>>> Matthew
>>>
>>> _________________________________________________
>>>  For list-related administrative tasks:
>>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
>> _________________________________________________
>> For list-related administrative tasks:
>> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme