[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).
+1!
Cheers,
-Ryan
More information about the Haskell-Cafe
mailing list