There has been many propositions like this: J&, MZScheme's Unit,  
Selector Namespaces, Method Namespaces, Expander, Java Module System,  
Jiazzy, ... I could say another 20 more.

I see that the three main difficulties in adding a module system in a  
programming language are:
	- Turning non-modularized libraries into modularized one
	- Preserving backward compatibility
	- Getting the community accept the proposal

Cheers,
Alexandre


On 23 Jan 2008, at 08:28, Reinout Heeck wrote:

> Jason Johnson wrote:
>> Hi all,
>> Recently working in other high level languages I was thinking about
>> how modularity is accomplished in these systems and how we might  
>> do it
>> in Squeak.
>
>
> This is a recurring discussion and I often see suggestions like  
> yours: postulate a mechanism and discuss its viability. I would  
> call this the bottom-up approach.
>
> If we went top-down we could start with specifying what we want to  
> get from a module system. I recently came across a paper on J&  
> ('Jet') which starts out with a list of requirements we might want  
> to ponder in this regard:
>
>
>
> http://lambda-the-ultimate.org/node/2591
> "
> J&: Nested Intersection for Scalable Software Composition by  
> Nathaniel Nystrom, Xin Qi, Andrew C. Myers. 2006.
>
>     We identify the following requirements for general extension  
> and composition of software systems:
>
>        1. Orthogonal extension: Extensions may require both new  
> data types and new operations.
>        2. Type safety: Extensions cannot create run-time type errors.
>        3. Modularity: The base system can be extended without  
> modifying or recompiling its code.
>        4. Scalability: Extensions should be scalable. The amount of  
> code needed should be proportional to the functionality added.
>        5. Non-destructive extension: The base system should still  
> be available for use within the extended system.
>        6. Composability of extensions.
>
>     The first three of these requirements correspond to Wadler’s  
> expression problem. Scalability (4) is often but not necessarily  
> satisfied by supporting separate compilation; it is important for  
> extending large software. Non-destructive extension (5) enables  
> existing clients of the base system and also the extended system  
> itself to interoperate with code and data of the base system, an  
> important requirement for backward compatibility. Nested  
> inheritance addresses the first five requirements, but it does not  
> support extension composition. Nested intersection adds this  
> capability.
> "
>
>
> IMO point 5 is often overlooked in Smalltalk systems, we love  
> extending base code but we hardly ever think about isolating these  
> extensions so the base code dependents don't get 'confused' by  
> those extensions.
>
>
>
> R
> -
>

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.