"Simon Marlow" wrote:

You're combining two extensions here - type signatures in export lists and tagging exported entities. Not a problem, but I don't think they're inextricably linked.

Indeed. I made them separate pages on the wiki. They were combined in my email only because Simon PJ asked how they related to each other. Although I now see that was not really his question at all.

But you don't need to go so far as to indicate the difference between type/data/newtype - just differentiating classes from tycons is enough to separate the namespaces.

Yes. However it could be slightly confusing that one writes "newtype" in the module body, but "data" in the module header?

It's less clear to me whether type and data/newtype should be distinguished or not, which is why I asked the question.

They are already distinguished in ghc. It always complains to me when I write Foo(..) in an export list, where the Foo is a type synonym rather than a datatype. (Not that I necessarily agree with ghc's behaviour here... :-) You will notice that for this reason, the export production for "type Foo" does not permit a subordinate list. However, I would be equally happy to combine type/newtype/data into a single keyword for exports.

BTW, I think Simon PJ was asking about how to *declare* types & classes in export lists, given that you're adding signatures to export lists which are a kind of declaration. If you want to put more of the interface into the export list, shouldn't you put it all in?

Yes, I see the point. In the fullness of time, perhaps we will indeed specify the module interface in full, including datatype definitions. But for the moment, I am more interested in regularising existing practice. Regards, Malcolm

On Wed, Feb 22, 2006 at 05:11:26PM -0000, Simon Marlow wrote:

Indeed, the distinction between data & newtype should be a completely private property, so we certainly shouldn't distinguish those in exports/imports. It's less clear to me whether type and data/newtype should be distinguished or not, which is why I asked the question. I'm not sure I agree with John's answer, I'd rather just say 'type' or 'data', using 'data' for both data and newtype, like Haddock does.

my best argument against this is to try to compile the following under ghc in strict haskell 98 mode

class Foo a instance Foo IOError

oops! Even if the restriction on synonyms in instance heads is lifted, being able to use type synonyms to give true aliases for types is important part of writing interfaces that can evolve and encapsulating implementation details. But more importantly, The haskell module system has a nice philosophy of just being about controlling the namespace of what is in scope in a module. Conflating representation details with it would just confuse things. I'd say use 'type' for everything in the type namespace, class for everything in the class namespace, value (or nothing) for things in the value namespace and so forth. We want the module system to describe precicely what names are in scope and what entities names in a module map too, nothing more. It is also a much simpler set of rules to remember and much more straightforward to specify. John -- John Meacham - ⑆repetae.net⑆john⑈