[clean-list] Comments on the module system

[Brian Rogoff]

Marco Kesseler writes:
> >Mercury is probably the most similar to Clean, check out 
> >
> >http://www.cs.mu.oz.au/research/mercury/information/doc-latest/refere
> >nce_manual_9.html#SEC58
> >
> >for a reference. The main difference is that Mercury merges interface and
> >implementation files. 
> 
> Thanks. I had a quick look at it. The only thing that is not entirely 
> clear to me, is whether you can refer to submodule definitions by 
> using merely the name of the parent module as a qualifier (i.e. not 
> main.sub.f but just main.f).

In any nested module system, you refer to the entity T in submodule 
Foo.Bar.Baz as Foo.Bar.Baz.T (assuming the "." separator). Usually 
such systems provide the equivalent of import; in ML, it's "open", in Ada 
"use", which must always be accompanied by a redundant "with" for the
compilation unit.  

> >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 am not sure what good nested modules Mercury really bring, in 
> addition to a module system like Clean has (and local functions). 

Well, I tend to think that a hierarchy of modules can better reflect the
hierarchy of a large system than can a flat module system, but no less a 
person than Niklaus Wirth disagrees. I quote from his "Compiler Construction"

       It is tempting to postulate that modules be nestable like
       procedures. This facility is offered for example by the language
       Modula-2. In practice, however, this flexibility has hardly been
       fruitful. A flat module structure usually suffices.

I disagree with his assertions about the state of practice, and apparently
so did the Ada-95 designers, as one of the more significant changes going
from Ada-83 to Ada-95 was the addition of child packages, and the language
change process was driven by user requests. 

> addition, I am not quite certain what you mean by 'hierarchical 
> namespace like Java'. I believe that Java does not even have 
> _hierarchical_ namespaces. As far as I know, it just allows dots 
> within package names, so it _suggests_ some hierarchy.

It also demands that the files be located in the directory structure in a
way dictated by those dot separated names. 

> C# has done things less like Java and more like C++, and I am 
> actually suggesting something similar. Some would call this approach 
> 'simpler'. I believe that some have crisitised the Java namespace 
> (package) organisation for being too tied to the file system 
> hierarchy (sorry, I can't remember when and where).
> 
> Anyway: it seems to me that simple hierarchical namespaces are 
> sufficient.

I'm a strong proponent of nested modules, but I believe that simply
having qualified imports would be a very useful, simple addition.  

> >What's the problem with just creating a new module which imports the one
> >you want to extend, and adds the additional stuff?
> 
> Too me, this still seems a bit confusing: if I import the extended 
> module, can I use the extended module name as a qualifier for _all_ 
> that is (indirectly) defined in it? (i.e. without having to specify 
> the submodules). And if I only import a submodule - or a single 
> function from a submodule), should I then suddenly use the submodule 
> as a qualifier? This does not sound entirely right.

I'm confused, I thought your question was about how to do this with Clean
now, not how this would work in a hierarchical module system. In a
hierarchical module system you refer to entities just like you refer to
them in a hierarchical file system without relative paths. You can shortcut 
the path by importing (open-ing or use-ing) a prefix section of the
path. It's really quite simple. 

-- Brian