concrete functor and monad transformers
#78Why Alternative instances require MonadPlus?
Alternative instances are typically defined as
instance (Monoid w, Functor m, MonadPlus m) => Alternative (AccumT w m)
instead of more symmetric
instance (Monoid w, Alternative m, Monad m) => Alternative (AccumT w m)
Would a patch changing this be accepted?
+1 to this
I posted an issue with a diff a while back somewhat related to this: https://hub.darcs.net/ross/transformers/issue/60. The questions from Ross in response might be useful. That issue was about StateT, specifically, which has an Applicative instance which already requires Monad. It looks like AccumT's Applicative also requires Monad, so I wonder if the reasoning is the same?
+1.
RE: Ross's questions in the other thread (does anything have Monad+Alternative but not MonadPlus?) -
I have a monad similar to the Validation monad, which is like the Either monad, except it attempts to collect all errors possible (e.g. anything thrown in an Applicative context). It still has a Monad instance in which case it will just fail with one error, but has the ability to collect as much as possible.
Validation violates the Right Zero law of MonadPlus, which states that for any m:
m >> mzero = mzero. This fails for my Validation monad, as>>is defined as*>and if errors are thrown inm, the result would still contain those errors.
