[Haskell-cafe] MPTC vs. constructor class

David Feuer david.feuer at gmail.com
Fri Mar 11 18:13:48 UTC 2016

I've been messing around with type-aligned sequences for a while, and
I'm currently exploring the design space of classes for them. The
type-aligned package uses this:

class TASequence s where
tempty :: s c x x Source
tsingleton :: c x y -> s c x y
-- can default to tsingleton = ( <| tempty )
-- but doesn't for some reason
(><) :: s c x y -> s c y z -> s c x z
tviewl :: s c x y -> TAViewL s c x y
tviewr :: s c x y -> TAViewR s c x y
(|>) :: s c x y -> c y z -> s c x z
(<|) :: c x y -> s c y z -> s c x z
tmap :: (forall x y. c x y -> d x y) -> s c x y -> s d x y

An obvious (to me) improvement is to add TAFunctor, TAFoldable, and
TATraversable classes, make TASequence a subclass of TATraversable,
and remove tmap from TASequence. That's one pleasant direction.

Another class expressing some of these ideas:

class Category s => TASequence' s c | s -> c where
  tviewl :: s x y -> TAViewL s c x y
  tviewr :: s x y -> TAViewR s c x y

  (|>) :: s x y -> c y z -> s x z
  (<|) :: c x y -> s y z -> s x z

This variant actually offers all the functionality of the original
except tmap, which it has no way to talk about whatsoever. The
Category s constraint allows id to replace tempty and (>>>) to replace
(><). I really like this aspect.

Unfortunately, losing tmap et al sucks. It's possible to glue that on
to the original TASequence using Data.Constraint:

class ForallF Category s => TASequence s where ...

but then accessing the Category instances requires mucking about with
(\\) and instF and throwing a bunch of explicit type signatures
around. Is there any good "design pattern" to resolve this conflict?

David Feuer

More information about the Haskell-Cafe mailing list