[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