[Haskell-cafe] The type class wilderness + Separating instances and implementations into separate packages
johan.tibell at gmail.com
Thu Nov 3 01:58:04 CET 2011
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
> 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"
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:
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
I would hope that we could get all the important interfaces into the
Haskell Platform eventually (and have all packages there use them).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe