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

On 11/20/10 1:13 PM, Johan Tibell wrote:

On Sat, Nov 20, 2010 at 3:53 PM, Maciej Piechotka 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