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.<div>
<br></div><div><div>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.</div>
<div><br></div>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.<br>
<div><br></div><div>-Edward<br><br><div class="gmail_quote">On Tue, Aug 13, 2013 at 8:12 AM, Ross Paterson <span dir="ltr"><<a href="mailto:R.Paterson@city.ac.uk" target="_blank">R.Paterson@city.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Aug 13, 2013 at 10:36:16AM +0200, David Luposchainsky wrote:<br>
> Another discussion that didn't reach conclusion: "Proposal to solve the<br>
> `EitherT` problem." Let's do some proposal cleanup :-)<br>
><br>
> On 2013-06-16 23:52, Gabriel Gonzalez wrote:<br>
><br>
> > Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and<br>
> have them both implement `MonadError`.<br>
><br>
> That's the one I would recommend.<br>
><br>
> - Doesn't break anything, and gets rid of the "exception-vs-error"<br>
> discussion.<br>
><br>
> - Not all uses of Either are to distinguish between success and failure,<br>
> sometimes it's just a convenient way of short-circuiting.<br>
><br>
> - Fits in well with all the other transformers of type "MonadT".<br>
><br>
> - MonadError instance makes possible use as throw-catch-y transformer clear.<br>
<br>
</div>My preference is to call the new transformer ExceptT, with a basic<br>
monad called Except, in line with most of the other transformers, and<br>
to deprecate ErrorT. (The rationale for the name is that Either isn't<br>
just for exceptions, and exceptions aren't just for errors.)<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm a bit unsure about the MonadPlus/Alternative instance. The exception<br>
type needs a default element to implement mzero, which the EitherT<br>
implementation obtains with a Monoid constraint, and then has mplus<br>
collecting exceptions. This could give surprising behaviour if your<br>
exception type is String, say.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>-Edward</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div></div>