[Haskell-cafe] The type class wilderness + Separating instances and implementations into separate packages

[Johan Tibell]

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

On Wed, Nov 2, 2011 at 11:28 AM, Ryan Newton <rrnewton at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111102/22f9fb16/attachment.htm>