Export lists in modules

[Simon Marlow]

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