Ok, I had several discussions with other people before posting here because I wanted to get this right. They all showed me that all the problems I described boil down to the lack of polymorphic constraints.
The simplest example of this problem is the MonadPlus
class, defined as:
class MonadPlus m where
mzero :: m a
mplus :: m a -> m a -> m a
... with the following laws:
mzero `mplus` m = m
m `mplus` mzero = m
(m1 `mplus` m2) `mplus` m3 = m1 `mplus` (m2 `mplus` m3)
Notice that these are the Monoid
laws, where the Monoid
class is given by:
class Monoid a where
mempty :: a
mappend :: a -> a -> a
mempty `mplus` a = a
a `mplus` mempty = a
(a1 `mplus` a2) `mplus` a3 = a1 `mplus` (a2 `mplus` a3)
So why do we even have the MonadPlus
class? The reason is because Haskell forbids us from writing constraints of the form:
(forall a . Monoid (m a)) => ...
So Haskell programmers must work around this flaw of the type system by defining a separate class to handle this particular polymorphic case.
However, this isn't always a viable solution. For example, in my own work on the pipes
library, I frequently encountered the need to pose constraints of the form:
(forall a' a b' b . Monad (p a a' b' b m)) => ...
Unlike the MonadPlus
solution, I cannot afford to switch the Monad
type class to a different type class to get around the polymorphic constraint problem because then users of my library would lose do
notation, which is a high price to pay.
This also comes up when composing transformers, both monad transformers and the proxy transformers I include in my library. We'd like to write something like:
data Compose t1 t2 m r = C (t1 (t2 m) r)
instance (MonadTrans t1, MonadTrans t2) => MonadTrans (Compose t1 t2) where
lift = C . lift . lift
This first attempt doesn't work because lift
does not constrain its result to be a Monad
. We'd actually need:
class (forall m . Monad m => Monad (t m)) => MonadTrans t where
lift :: (Monad m) => m r -> t m r
... but Haskell's constraint system does not permit that.
This problem will grow more and more pronounced as Haskell users move on to type constructors of higher kinds. You will typically have a type class of the form:
class SomeClass someHigherKindedTypeConstructor where
...
... but you will want to constrain some lower-kinded derived type constructor:
class (SomeConstraint (someHigherKindedTypeConstructor a b c))
=> SomeClass someHigherKindedTypeConstructor where
...
However, without polymorphic constraints, that constraint is not legal. I've been the one complaining about this problem the most recently because my pipes
library uses types of very high kinds, so I run into this problem constantly.
There are workarounds using data types that several people have proposed to me, but I haven't (yet) had the time to evaluate them to understand which extensions they require or which one solves my problem correctly. Somebody more familiar with this issue could perhaps provide a separate answer detailing the solution to this and why it works.