These are all very good questions! Here's my stab at it:
On Wed, Nov 2, 2011 at 11:28 AM, Ryan Newton
What is the right interface for a queue? What is the right interface for a random number generator?
For any given class I'd try to get a few experts/interested parties together and discuss.
I don't know, but in both cases you will find many packages on hackage offering different takes on the matter. In fact, there is a wilderness of alternative interfaces. We've had various discussions on this list about the number of alternative packages.
The lack of cohesion in our library offerings is a problem and so is the lack of interfaces. We end up programming against concrete types way too often.
I'm fine with lots of packages, but I think it would be great if not every package introduced a new interface as well as a new implementation. If we could agree as a community on common interfaces to use for some basics, that would probably go a long way towards taming the type class wilderness. People have mentioned this problem before with respect to "Collections" generally.
Aside: The problem with collections is that we don't have the programming language means to do this well yet (although soon!). The issue is that we want to declare a type class where the context of the methods depends on the instance e.g. class MapLike m where type Ctx :: Context -- Can't do this today! insert Ctx => k -> v -> m -> m Java et all cheats in their container hierarchy by doing unsafe casts (i.e. they never solved this problem)!
One basic part of reaching such a goal is separating interface from implementation. I ran into the following problems just in the last 24 hours. In both cases I wanted to use a type class, but didn't want to depend on the whole package it lived in:
- I wanted to use the Benchmarkable class in Criterion in my package. (Criterion deserving to be a "standard" package.) But I can't get that typeclass without depending on the whole Criterion package, which has several dependencies. And in fact on the machine I was on at the time some of those dependencies were broken, so I decided not to use Benchmarkable. - I wanted to use, or at least support, an existing class for Queues. I found the following:
http://hackage.haskell.org/packages/archive/queuelike/1.0.9/doc/html/Data-MQ...
I think the best option at the moment is to break out type classes in their own packages. That's what I did with hashable. How can we enumerate packages that at least purport to provide standard
interfaces that you should both use and pick up to implement? On a Wiki page?
I would hope that we could get all the important interfaces into the Haskell Platform eventually (and have all packages there use them). -- Johan