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

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

On 16/09/05, Tom Hawkins 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