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.
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.
> I also think that the monad instances on Either and (,) are abuses. (And
the monad instance on (->), too, since once I got a hard to find error
where a missing argument in a function call was interpreted as an instance
of the Reader monad.)
I think that this position is too extreme. The use of the `Either` monad for error handling is Haskell canon and is more widely understood than even monad transformers. The logical conclusion of what you are proposing is to duplicate all `Either` machinery once for each potential application of `Either`.
That's not to say that there shouldn't be isomorphic types with names and behaviors tailored to specific application domains. I understand the perils of "boolean blindness" (and its equivalent for other types). However, there needs to be space in the standard libraries for the neutral approach otherwise you will fragment the library ecosystem considerably.