Proposal to solve the `EitherT` problem.

[Ross Paterson]

On Mon, Jun 17, 2013 at 01:14:23PM -0700, Gabriel Gonzalez wrote:
>     Fair point, but then EitherT is too neutral, giving no hint of the purpose
>     of the monad instance, and suggesting a symmetry that is absent from the
>     monad: Right is normal monadic sequencing, while Left is the exceptional
>     control path.  Things get particularly 'sinister' when you get to naming
>     the throw and catch combinators.  It's a bit like the reason for having
>     Writer instead of using the monad instance for (,).  So I'd lean more to
>     something like Except, which would also be in line with Moggi's original
>     presentation of this monat and transformer.
> 
> However, there is prior art (i.e. the existing name of `Either`).
> Using a different name for the monad and the monad transformer seems
> like bad form to me.

Indeed having a differents name for the monad and monad transformer was
always another of the flaws of ErrorT, but there's another way to fix
that, and more in line with the treatment of the other monad transformers
(with the exception of MaybeT).

> This is also a good argument for keeping both monad transformers in
> `transformers`.  `ErrorT` satisfies the people who want a meaningful
> name and `EitherT` satisfies the people who prefer a neutral purpose.

Actually it isn't: you've shown that the name Error is too limited and
I've shown that Either is too broad.