And yet, because many of the users of the library are just using Either, both will still probably have to exist anyways unless Gabriel also wants to raise a similar hue and cry. 

My experience from talking to folks is that they start using errors with Either and then upgrade to EitherT since they already know how to use the basic combinators. The loss of that pedagogical vector to adoption would be a rather big blow to the adoption of the package.

The nature of those combinators is that people use them to reduce the noise in their code. EitherT e Identity is noisier than Either to pattern match on and work with when you're done tossing code through errors combinators.

-Edward


On Thu, Aug 15, 2013 at 10:50 AM, Ross Paterson <R.Paterson@city.ac.uk> 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.

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