[clean-list] Comments on the module system

[Marco Kesseler]

>> 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/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).

>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). In 
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.

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 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?

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.

On the other hand, if I always have to specify the exact (path to a) 
submodule in which something has been specified, I run into problems 
when I move a definition to another module. The happens both for 
physical (file system) paths and logical (import chain) paths.

>> 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. 

That is very true, I suppose.

regards,
Marco.