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