RFC: Adding a Hashable type class and HashMap/HashSet data types to HP

[wren ng thornton]

On 11/20/10 1:13 PM, Johan Tibell wrote:
> On Sat, Nov 20, 2010 at 3:53 PM, Maciej Piechotka<uzytkownik2 at gmail.com>  wrote:
>> Shouldn't it be:
>>
>> class Eq a =>  Hashable a where
>>         hash :: a ->  Word
>>
>> Or is there useful case where we want to hash something but it cannot be
>> member of Eq?
>
> I can think of a few. Regardless, constraining the type class in this
> way doesn't really buy us anything.

Unless there's a really good reason why a class should require a 
superclass, it's best to leave them off. Even if one can't think of good 
examples at the time of designing the class.

True inheritance/subsumption hierarchies like Functor/Applicative/Monad 
are an example of a good reason to have them. 
Functor/Foldable/Traversable is another. Eq/Ord is another, though some 
consider it questionable (other than the omission of a PartialOrd class, 
I'm not sure why).

On the gripping hand, Eq/Num and Show/Num are excellent examples of 
where adding unnecessary constraints just makes things harder for 
everyone. I see no reason why the ability to hash a value should entail 
decidable equality checking for those values, nor how 'hash' would allow 
us to flawlessly reconstruct definitions of (==)/(/=).

-- 
Live well,
~wren