Proposal to solve the `EitherT` problem.

[Jeff Shaw]

On Tuesday, June 18, 2013 3:44:07 PM, Ross Paterson wrote:
> 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.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

I found that the meaning of EitherT was completely obvious to me while 
I was learning Haskell. Either is always introduced early on as a way 
to return error values, and so after learning what Monad Transformers 
are for, EitherT was a natural name. I found ErrorT to be useless as it 
was too restrictive.

Jeff