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

[wren ng thornton]

On 11/24/10 11:41 AM, Duncan Coutts wrote:
> On 22 November 2010 01:19, wren ng thornton wrote:
>> +1. Especially given the recent trend towards breaking things out of base,
>> moving this in is suspect. As folks have been moving towards base-4 we've
>> been able to finally start getting rid of the slew of Cabal flags for
>> figuring out when base does or does not include various libraries. Don't
>> start inventing new ones :)
>
> It's not a simple question of "put stuff in base" vs "take stuff out
> of base" one has to look at what it is that it makes sense to put in /
> take out. The things we have been removing from base have mainly been
> independent implementations of things, not standard interfaces. There
> is a pretty reasonable argument that standard interfaces -- especially
> type classes -- should go in base, while almost all implementation do
> not need to be.

Right. My implication was that the module in question doesn't seem like 
the kind of thing that should go in base. Generally used classes (sans 
implementations) tend toward moving into base because having the class 
sans implementation in its own package is cumbersome[1], and having the 
class with its implementations introduces unnecessary dependencies. 
However, that doesn't mean that all widely used classes should move into 
base. For instance, consider the popular library Foo which defines a 
FooClass; because Foo is widely used, FooClass will be too, but if Foo 
is a graphics library or some other domain-specific thing, then FooClass 
may not have the kind of generality that's appropriate for base classes.

While the idea of hashing is certainly general enough, I don't know that 
this particular class definition of the idea is.[2] Compare against the 
current development of classes for randomly generating values. The base 
class is problematic, as has been known for some time, but the new 
classes aren't settled in stone yet either. Not to mention that 
QuickCheck, SmallCheck, etc have classes with similar goals of 
constructing values "out of nothing" but whose goal is very different 
than the statistically random generation of types like Int or Double. I 
anticipate similar issues happening with hashing a few years down the 
road once people have played around with the hashable/hashmap packages 
more, and therefore do not think it should be included in base.


[1] Though not necessarily a bad idea. If each independent family of 
classes were in their own package, then we could give those families 
version numbers of their own instead of trying to remember which version 
of base/quickcheck/... added or removed some particular method. This, on 
the whole, strikes me as a good idea since it puts the version numbers 
where they belong and makes it clearer for using CPP to conditionalize 
parts of the implementation. Unfortunately, it's a heavyweight solution 
and cabal doesn't seem like quite the right tool to be tracking this 
sort of thing.

[2] Things like groups, fields, etc have well-defined interfaces and so 
it's easy to see whether they are complete and appropriate or not 
(ignoring debates about whether the algebraic classes are the right 
generalizations to be used). Even things like a class for monad 
transformers are defined almost entirely based on the types that things 
must have. But hashing doesn't have the same kind of well-defined 
structure as either of these.

-- 
Live well,
~wren