[Haskell-cafe] Re: Type class help please

Adrian Hey ahey at iee.org
Wed May 16 06:01:32 EDT 2007


oleg at pobox.com wrote:
> Adrian Hey wrote:
>> -- Instances of GT are instances of Eq --
>> instance (GT map key, Eq a) => Eq (map a) where
>>   map1 == map2 = assocsAscending map1 == assocsAscending map2
>> ...
>>      Overlapping instances for Eq [(key, a)]
>>        arising from use of `==' at Test.hs:10:16-59
>>      Matching instances:
>>        instance (Eq a) => Eq [a] -- Defined in GHC.Base
>>        instance (GT map key, Eq a) => Eq (map a) -- Defined at Test.hs:9:0
>>
>> How can my new instance overlap with the old (ghc) instance unless
>> [] is also an instance of GT for some key type (which it isn't).
>> Could someone explain?
> 
> You are right in your explanation of the GHC behavior. Your instance 
> |Eq (map a)| indeed overlaps the `standard` instance |Eq [a]|. The
> overlap may be easier to see if we write [a] as ([] a), which is what
> it is, an application of the type constructor [] to the type variable
> a. So, the type [a] (aka [] a) is a particular instance of the type
> (map a), with `map' being []. This is the overlapping that GHC is
> complaining about.

So if I understand correctly, it's complaining about a potential
overlap, not an actual overlap (there is no actual overlap until []
is made an instance of GT AFAICS).

Also, I suspect I'm still missing something important here, for
example I don't understand why, if it overlaps for [], it doesn't
overlap with other instances (like Maybe for example). Or am I
just not getting the error for Maybe because ghc stops after
the first error?

> Another solution is replacing the general instance
> instance (GT map key, Eq a) => Eq (map a) where
>   map1 == map2 = assocsAscending map1 == assocsAscending map2
> 
> with its instantiations, for all `maps' in question:
> instance Eq a => Eq (Data.IntMap a) where ...
> instance Eq a => Eq (Data.Map key a) where ...
> instance Eq a => Eq (Data.IntSet a) where ...

This seems like the more attractive option if my current approach
is unworkable, but it seems strange that I should have to do
this.

Thanks
--
Adrian Hey



More information about the Haskell-Cafe mailing list