[Haskell-cafe] Eq Type Class: Overloading (==)

Jason Dagit dagit at eecs.oregonstate.edu
Sat Sep 17 02:14:14 EDT 2005


On Sep 16, 2005, at 10:13 PM, Cale Gibbard wrote:

> On 16/09/05, Tom Hawkins <tom at confluent.org> wrote:
>
>> Hello,
>>
>> Is it possible to overload (==) to a type other than a -> a -> Bool?
>>
>> I have an abstract datatype that somewhat behaves like a C integer: a
>> comparison returns a boolean represented as the same datatype:
>>
>> (==) :: my_type -> my_type -> my_type
>>
>> Thanks for any help!
>>
>> -Tom
>>
>
> You largely wouldn't want to -- the thing that makes the usual type
> for (==) useful is that lots of functions make use of the Bool result
> with if/then/else. If you change the Eq typeclass, then a large chunk
> of the standard library is going to break, and it won't be all that
> easy to correct, because if-then-else-expressions all expect a Bool.
> You'd want to add a typeclass for boolean-interpretable values, and
> fix up ghc to use it with if-expressions.

This reminds me that several times now I've wished that Bool was some  
sort of interface instead of a type.  Perhaps Bool could be a type  
class?  I also wish that "if" were a function, but that's probably  
just the lisper in me speaking.  Something like:

if :: Bool b => b -> a -> a-> a

I guess my biggest reason for this is purely convenience, and I  
wonder if this would just weaken the type system.  Say for example,

instance Bool Int where
       true = not false
       false = 0
       -- probably need definitions of and, or, not
       -- it may also be useful to have things like isTrue and isFalse

Then you could do things like:
if 1 then x else y

And we all know that's not the best thing to have around.

Although, I'm not sure if this is a strong argument not have a Bool  
type class.  After all, lists can be turned into Nums and that's odd  
in subtle ways as far as detecting common typos is concerned.

http://haskell.org/hawiki/CodeExamples#head- 
c926349e876dca4d1324036fe67a6eb1fe7afb3c

If you use that code then (0:1) becomes valid even though it would  
normally be a type error.

Just some stuff to think about.

Thanks,
Jason


More information about the Haskell-Cafe mailing list