[clean-list] Comments on the module system

[Brian Rogoff]

Marco Kesseler writes:
> >If you mean that hierarchical namespaces shouldn't map to filesystem 
> >directory
> >hierarchy, I agree. However, I think modules should define scopes. Think of 
> >the ML module system without functors, or Ada packages without generics. 
> >Mercury, which is a kind of cousin to Clean, is a good source of design
> >ideas here (though I prefer separate interface and implementation modules 
> >like Clean and Ada).
> 
> Modules already define scopes, in the public/private sense, but I 
> would not couple this to namespaces.
> 
> I am not too familiar with the ML, Ada and Mercury solution. 

Mercury is probably the most similar to Clean, check out 

http://www.cs.mu.oz.au/research/mercury/information/doc-latest/reference_manual_9.html#SEC58

for a reference. The main difference is that Mercury merges interface and
implementation files. 

The issue I was bringing up is whether we want nested modules, like 
Mercury (and Ada, and ML, ...) or a simple hierarchical namespace like 
Java. Note that in Ada a child package has access to all of the visible 
specification of its ancestors (as though all ancestors were imported) 
whereas in Java this isn't the case. I'd prefer true nesting. 

> I think
> that it would be useful to add definitions to a particular namespace 
> without
> having to add it to a particular module.
> 
> Consider for example the case that one wants to extend some 
> 'standard' namespace with new definitions. In such a case it is 
> probably unwise to
> touch the original implementation modules, even if one does have the
> sources.

What's the problem with just creating a new module which imports the one
you want to extend, and adds the additional stuff? 

> Furthermore, in a system of reasonable size, there will often be a lot
> of modules, which makes it hard for a programmmer to find out in which
> module a particular definition resides. A library of a particular party
> will usually have no conflicting names. These could all be placed in a
> single namespace, which is quite convenient, and easy to remember.

This is why I want qualified names, and a better way to carve up a 
namespace, namely hierarchy. The nice thing is that increasing the power of 
Cleans module system is pretty straightforward and doesn't require any
heavy type theory. 

-- Brian