Re: separate class and type namespace

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