Proposal to solve the `EitherT` problem.

[Ross Paterson]

On Mon, Jun 17, 2013 at 11:27:18AM -0700, Gabriel Gonzalez wrote:
>     On Sun, Jun 16, 2013 at 02:52:46PM -0700, Gabriel Gonzalez wrote:
>     > There are three approaches that I'd like to submit for consideration
>     > and receive feedback on:
>     >
>     > * Approach 1: Remove the `Error` constraint from `transformers`
>     >
>     > Disadvantage: This silently breaks all existing uses of `fail`.  I
>     > don't know any way to add a compiler warning to notify downstream
>     > libraries of this change.
> 
> I'm going to add another disadvantage of this approach: `ErrorT`
> is not as good of a name.  `EitherT` is a more neutral name, which
> matters if you want to use it for non-error-based flow control like
> the way I describe here:
> 
> http://www.haskellforall.com/2012/07/breaking-from-loop.html

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.