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

Ryan Newton rrnewton at gmail.com
Thu Nov 3 14:56:47 CET 2011

> 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.
Indeed!  I greatly believe in this mantra now.  Really, my point was
only this banal one -- packages with only interfaces in them have no
dependencies and are much less likely than implementation packages to
break when the GHC version changes.

> 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)!

Ah, interesting.  Is there a proposal to do this?  While we need to
avoid an infinite regress of generalization and abstraction (type
programming => kind programming?, etc) -- it does seem like class
contexts on types and type class instances themselves would be nice to
have *some* control over.  (In the above message, for example I was
having trouble due to not being able to hide instances on import.)

> I would hope that we could get all the important interfaces into the Haskell
> Platform eventually (and have all packages there use them).



More information about the Haskell-Cafe mailing list