Proposal to solve the `EitherT` problem.

[Gabriel Gonzalez]

On 08/15/2013 07:50 AM, Ross Paterson wrote:
> On Wed, Aug 14, 2013 at 10:51:01AM -0400, Edward Kmett wrote:
>> I was trying to fire off one last shot across the bow that in the big 2.0
>> switch there was a move to make "State s" be "StateT s Identity" that was
>> mostly argued for code reuse and simplification reasons, that it cut code
>> duplication by a factor of 2 in the body of transformers and the mtl and
>> reduced the chance for human error.
>>
>> The fact that State s = StateT s Identity rather than merely being isomorphic
>> seems to me to be an emergent property of this change, not its purpose.
> I think there's still mileage in that argument.  For example, the module
> Control.Error.Safe in the errors package has 13 functions of the form
>
> 	fooErr :: e -> args -> Either e r
>
> and another 13 of the form
>
> 	tryFoo :: Monad m => e -> args -> EitherT e m r
>
> If the recommended base exception monad were a specialization of the
> recommended transformer, only one set would be needed.

Like I said before, you can always define:

     type Except e = EitherT e Identity

That way people who want to ignore the base monad can use `Except`.

However, there is no way that I'm getting rid of the `Either` functions 
from `errors` even if `transformers` has `Except`. `Either` is here to 
stay, and people need those `Either` functions.

Don't get me wrong: I use `transformers` exclusively for effects, to a 
fault even.  However, I think `Either` is more fundamental than 
`transformers` and that there is no way an `Identity`-specialized 
`EitherT` will ever supplant the use of `Either`.

> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries