"Simon Marlow"
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