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. Of course, this can be done in Haskell by putting the class declaration inside a module, but doing so can be annoying, and I think this style clearly attaches the method to the class it belongs to. It thereby lets you have a List l=>List.empty::l and also a Bag b=>Bag.empty::b automatically. Then there are types and instance declarations. I have the strange feeling that they go together. So I'm thinking it might be good to have some kind of type/instance module that can export types and instances. I can't understand why it is that instance declarations can't contain nested declarations other than the required ones. I think it would be nice if they could contain other declarations, as modules can. Also, instances could be imported (not just as part of a module, but separately) ML-style structures/functors. For everything else. Finally: I want nested modules!!! They probably couldn't be compiled separately, but they'd provide some namespace control. -- /Times-Bold 40 selectfont/n{moveto}def/m{gsave true charpath clip 72 400 n 300 -4 1{dup 160 300 3 -1 roll 0 360 arc 300 div 1 1 sethsbcolor fill}for grestore 0 -60 rmoveto}def 72 500 n(This message has been)m (brought to you by the)m(letter alpha and the number pi.)m(David Feuer) m(David_Feuer@brown.edu)m showpage
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
participants (2)
-
David Feuer -
Fergus Henderson