Proposal to solve the `EitherT` problem.

[Edward Kmett]

An argument against just randomly bikeshedding the name it is there are a
lot of packages out there currently transitively depending on the existing
either package, due to the popularity of Tekmo's errors package and the
fact that it has been picked up by snap. So half of the web-apps in the
ecosystem depend on this type transitively.

Renaming it means that folks have to make a sharp cut-off in support, and
there are folks out there like the snap community, who use the current
version and support 3 major versions of GHC and all attendant platforms.

EitherT is literally the coproduct of the Either monad and any other monad,
made possible by fact that Either is ideal and so can commute, so in
essence EitherT is the most 'free' construction involving Either, while
ErrorT is the special case.

-Edward

On Tue, Aug 13, 2013 at 8:12 AM, Ross Paterson <R.Paterson at city.ac.uk>wrote:

> On Tue, Aug 13, 2013 at 10:36:16AM +0200, David Luposchainsky wrote:
> > Another discussion that didn't reach conclusion: "Proposal to solve the
> > `EitherT` problem." Let's do some proposal cleanup :-)
> >
> > On 2013-06-16 23:52, Gabriel Gonzalez wrote:
> >
> > > Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and
> > have them both implement `MonadError`.
> >
> > That's the one I would recommend.
> >
> > - Doesn't break anything, and gets rid of the "exception-vs-error"
> > discussion.
> >
> > - Not all uses of Either are to distinguish between success and failure,
> > sometimes it's just a convenient way of short-circuiting.
> >
> > - Fits in well with all the other transformers of type "MonadT".
> >
> > - MonadError instance makes possible use as throw-catch-y transformer
> clear.
>
> My preference is to call the new transformer ExceptT, with a basic
> monad called Except, in line with most of the other transformers, and
> to deprecate ErrorT.  (The rationale for the name is that Either isn't
> just for exceptions, and exceptions aren't just for errors.)
>

I'm a bit unsure about the MonadPlus/Alternative instance.  The exception
> type needs a default element to implement mzero, which the EitherT
> implementation obtains with a Monoid constraint, and then has mplus
> collecting exceptions.  This could give surprising behaviour if your
> exception type is String, say.


Haven't we managed to work out that there isn't a way to collect exceptions
in the left hand side of Either that also forms a Monad? I recall this
discussion coming up almost every time someone makes an Either/EitherT like
monad like \/ or validation in scalaz, because the kneejerk is to try to
accumulate errors in the Applicative, leading to an issue when you compare
it to the Monad.

-Edward


> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130813/035cbc1c/attachment.htm>