Musings about modularity and programming in the large
bergel at iam.unibe.ch
Thu Jan 24 04:07:00 UTC 2008
I spend some effort to summarize those work. If you are interested in
Related work in:
On 23 Jan 2008, at 15:16, Jason Johnson wrote:
> 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>
>> 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
>> 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:
>>> 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
>>> 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
>>> 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.
>> Alexandre Bergel http://www.bergel.eu
Alexandre Bergel http://www.bergel.eu
More information about the Squeak-dev