[plt-scheme] Why Modules?

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