proposal #4095: add Applicative instance for Either

[Edward Kmett]

On Tue, May 25, 2010 at 2:32 PM, Henning Thielemann <
schlepptop at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20100525/eaaf8dc1/attachment.html