On 23 February 2006 01:48, John Meacham wrote:
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!
Actually I wanted to distinguish type and data, and type and newtype, but not data and newtype (my lanugage was ambiguous, sorry about that).
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.
That's a fair point. I agree it's a nice property that the module system just talks about *names* and nothing else, and on that basis you're right that distinguishing type synonyms from other type constructors in export specifiers would be inconsistent. Cheers, Simon