RFC: Adding a Hashable type class and HashMap/HashSet data types
wren ng thornton
wren at freegeek.org
Sun Nov 21 20:14:48 EST 2010
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 (==)/(/=).
More information about the Libraries