"Simon Marlow"
However, I would be equally happy to combine type/newtype/data into a single keyword for exports.
for the record, I am in favour of tagging export specifiers with 'class' or 'type' (using 'type' for all type constructors, in light of yours and John's points).
For the sake of avoiding confusion, perhaps we should choose a keyword (or better, a reserved identifier with no meaning outside of the export/import list) that is none of "type", "data", or "newtype"? How about "datatype", "tycon", or the like? Then it would be clearer that there is no relationship between the way the type is defined, and how its namespace is notated in the export list.
If modules are to contain interfaces, I don't think extending the export list is the way to do it. I'd rather do something like: -------------------------------------- modules M exports
class Eq a where (==) :: a -> a -> Bool
data T :: * -> * f :: T -> Int mkT :: Int -> T
where -- implementation below here --------------------------------------
But, apart from adding fuller signatures than I proposed, that is exactly the same as an export list, modulo some very minor syntactic differences!
Not a proposal by any means, and I don't think that Haskell' should tackle this, but this seems the right direction to me.
I agree that full interface specs are beyond Haskell'. JPBernardy's argument that tools (Haddock, compilers) can already extract the interface automatically is quite persuasive too. Regards, Malcolm