Wonderful, thanks.  I dig through those and see if I find something
like what I'm envisioning.

On Jan 23, 2008 3:10 PM, Bergel, Alexandre <bergel at iam.unibe.ch> wrote:
> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>