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
