On Tue, Aug 13, 2013 at 8:12 AM, Ross Paterson
<R.Paterson@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