These are all very good questions! Here's my stab at it:

On Wed, Nov 2, 2011 at 11:28 AM, Ryan Newton <rrnewton@gmail.com> wrote:
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-MQueue-Class.html

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