[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