[Haskell-cafe] Eq Type Class: Overloading (==)
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:
>> 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!
> 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.
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.
More information about the Haskell-Cafe