Marcin 'Qrczak' Kowalczyk writes:

...

Type signatures too should be allowed in export lists.

I'm all for type signatures, but I am slightly worried in that this leads to duplication of information (giving the signature both in the export list and at the place of definition). What about having "private/public" access modifiers at the points of definition instead, and removing export lists altogether? If we know beforehand what functions of what names and types a module *must* export (by design), in other words, if the intention is that the compiler checks whether the implementation matches the exported specification, then we should write an interface (i. e. unary type class) and declare an instance. Then the module should export nothing but the instance. The problem with this is that an interface says something about a type while a Haskell module might export many things (functions, types) at the same time. So there is in fact no formal "interface" concept for modules, leading to mis-use of qualified imports for that (import qualified My_Bar as Bar, when I know that My_Bar behaves "as a Bar"). So a Haskell module is more like a Java package than a Java class. On the other hand, it is recommended practice to define only one data type per module, isn't it? Respectfully submitted, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

On the other hand, it is recommended practice to define only one data type per module, isn't it?

Only by very few people as far as I know. I know that Henning Thielemann advocates this, but it seems like a rather arbitrary restriction to me. I find it quite common to define several data types in a single module, so long as they're sufficiently related. Depending on how they are used, I may or may not export any one of them. Have a look at Basics.lhs in Haskore, then imagine separating that such that every one of those data types was in its own module. You'd end up with a lot of modules which only had one data type in them and nothing else. I think it's just better to use your own picture of how the project fits together to decide where to put things. Unless you're explicitly using modules for hiding data constructors, it doesn't seem necessary to structure your modules around your types. - Cale