[Haskell-cafe] Re: typeclass namespace rational?

[Jonathan Geddes]

2 seconds after sending I realized the issue is in module exports:

>Module String where (String(..))

is that exporting some concrete ADT with all of its constructors or an
abstract type class with all of its methods?

Its too bad that Classes and ADTs overlap in export syntax and as such
must share a namespace. I would much prefer

>Module String where (class String(..), data String(..), someOtherFunction)

which I think is easier for the reader anyway.

--Jonathan

On Mon, Nov 15, 2010 at 8:31 PM, Jonathan Geddes
<geddes.jonathan at gmail.com> wrote:
> cafe,
>
> Data Constructors and Type Constructors don't share the same
> namespace. You see code like the following all the time:
>
>> data MyRecord = MyRecord {...}
>
> This is possible because Data Constructors are used in different parts
> of the code than Type Constructors so there's never any ambiguity.
>
> Type Classes, on the other hand, share the same namespace as Type
> Constructors. You can't define this:
>
>>class String s where
>>    ...
>>
>>instance String String where
>>    ...
>>instance String ByteString where
>>   ...
>>instance String Text where
>>   ...
>
> Not that I'm running out of valid haskell identifiers or anything :P,
> I'm just wondering: what's the rationale behind keeping Type Classes
> and Type Constructors in the same namespace? I can't think of any
> ambiguity there would be if they each had their own namespace. And In
> some cases it would be convenient to be able to define both a concrete
> representation and an abstract one with the same name as in the String
> class example above.
>
> --Jonathan
>