On Tue, May 25, 2010 at 2:32 PM, Henning Thielemann < schlepptop@henning-thielemann.de> wrote:
Isaac Dupree schrieb:
Assuming we do want to keep Either having a Monad instance at all, we do as Ross says have to pick the "leftmost error" rather than "all errors" Applicative instance. (Monad cannot produce errors beyond the leftmost, due to its later-actions-depend-on-results-from-earlier-ones nature.)
I can live without the Monad Either instance.
I too would be much happier if the current Monad Either instance were to vanish from mtl/transformers/monads-(fd/tf) as the annoying Error constraint breaks a number of wonderful theoretical properties. In my perfect world the next version of transformers would provide an entry in Control.Monad.Instances for: instance Applicative (Either m) instance Alternative (Either m) instance Monad (Either m) instance MonadPlus (Either m) of which the instance for Applicative could be pushed up to Control.Applicative as part of this proposal, with Alternative making the move later and then Control.Monad.Error could follow suit with the way State, Reader and Writer are being redefined as type aliases of their transformers wrapped around identity, ditching the Either instance in favor of ErrorT e Identity for symmetry. Sadly, the class used by Control.Monad.Error is named Error, robbing us of the obvious name for the type alias. That said it would break a fair amount of existing code, and is a separate issue pertaining to a separate library and so should probably be considered on its own merits in another proposal as anything that relied on importing Control.Monad.Error and being able to then do [ x | Right x <- xs ] would break. But there are quite possibly too many moving parts to make such a big jump, and then you have the other bikeshedding issue of there being yet another definition for Either that makes sense to default to: instance Monoid m => Applicative (Either m) instance Monoid m => Alternative (Either m) instance Monoid m => Monad (Either m) instance Monoid m => MonadPlus (Either m) which would likely ensure that any such concrete proposal wings up stillborn. The former monad is nice for things like implementing generalized apomorphisms as generalized anamorphisms, for symmetry with implementing zygomorphisms (generalized paramorphisms) as generalized catamorphisms, the latter has less theoretical appeal but it is still easy to remember, convenient to use, and has a pseudo-symmetric relationship to Monoid m => Monad ((,) m). -Edward Kmett