On 14-Dec-2001, David Feuer
Well, I've been doing some more stupid thinking, and I've decided that I am not satisfied with the module system in haskell, or the way it deals with namespaces. It seems to me that there are four kinds of things that need to be dealt with: classes, instances, types, values, and possibly some kind of ML-style structures/functors.
I see no good reason not to treat a class declaration similarly to the way Haskell treats modules. For example, if I have a class
class A x where f1::... f2::...
I would like to access the functions by writing A.f1, A.f2, etc. There should, however, be some way to unqualify the names, the way ML allows structures to be opened.
A proposal very similar to this has recently been suggested on the mercury-developers mailing list [1]. This proposal, and others related to it, have then been discussed at some length. See the threads titled "Module qualification of typeclass methods" [1] "Automatic inclusion of modules" [2], and "Module system discussion" [3]. One drawback with this proposal was noted by Simon Taylor: | The proposal is also a step backwards for classes that are already | defined in a module of the same name, for example library/enum.m. | With the proposed change, the methods of that class would be | enum__enum__to_int and enum__enum__from_int.
Finally: I want nested modules!!! They probably couldn't be compiled separately, but they'd provide some namespace control.
Mercury supports separate compilation of sub-modules.
Mercury has two kinds of sub-modules, "nested modules",
which are physically nested in the same source file,
and "separate sub-modules", where the parent (containing) module
just contains a `:- include_module' declaration naming the child
module, and the source code for the child module occurs in a
separate file. You get separate compilation of separate sub-modules.
[1] http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/mer...
[2] <http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/m
ercury-developers.0111/0082.html>
[3] <http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/m
ercury-developers.0111/0097.html>.
--
Fergus Henderson