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