[plt-scheme] Why Modules?

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