>
> 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.
