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.