
On 22 February 2006 14:54, Malcolm Wallace wrote:
"Simon Peyton-Jones"
wrote: I don't seriously propose for haskell-prime that signatures should be required on exports. Just permitting them would be a large and useful step up already.
If this is to be a serious proposal, someone had better think what to do about classes, data types, instances and so on.
As far as I can see, there is very little to change. Here is a concrete proposal. A qvar in an export list may optionally have a type signature. A qtycon or qtycls in an export list may optionally have an annotation saying whether it is a type, newtype, data, or class. Instances cannot be mentioned in export lists, and this does not change.
export -> qvar | qtycon [ (..) | ( cname_1, ... , cname_n ) ] (n>=0) | qtycls [ (..) | ( var_1, ... , var_n ) ] (n>=0) | module modid
becomes
export -> qvar [ :: type ] | [type] qtycon | [newtype] qtycon [ (..) | ( cname_1, ... , cname_n ) (n>=0) | [data] qtycon [ (..) | ( cname_1, ... , cname_n ) (n>=0) | [class] qtycls [ (..) | ( var_1, ... , var_n ) (n>=0) | module modid
As far as import entity lists are concerned, we permit an optional annotation for type synonyms, newtypes, datatypes, and classes:
import -> var | tycon [ (..) | ( cname_1, ... , cname_n ) ] (n>=0) | tycls [ (..) | ( var_1, ... , var_n ) ] (n>=0)
becomes
import -> var | [type] tycon | [newtype] tycon [ (..) | ( cname_1, ... , cname_n ) ] (n>=0) | [data] tycon [ (..) | ( cname_1, ... , cname_n ) ] (n>=0) | [class] tycls [ (..) | ( var_1, ... , var_n ) ] (n>=0)
Anyone see any difficulties?
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. Regarding tagging of exported entities, see this message from John Meacham in a previous discussion: http://www.haskell.org//pipermail/haskell-prime/2006-January/000226.html basically tagging exports lets us completely separate the namespaces of classes and tycons (currently they share the same namespace, for no really good reason). 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. 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. 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? Cheers, Simon