separate class and type namespace

[Johannes Waldmann]

> Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> 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/ -------