Proposal to solve the `EitherT` problem.
gabriel439 at gmail.com
Thu Aug 15 20:09:30 CEST 2013
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
More information about the Libraries