Proposal to solve the `EitherT` problem.
ekmett at gmail.com
Thu Aug 15 17:20:37 CEST 2013
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.
On Thu, Aug 15, 2013 at 10:50 AM, Ross Paterson <R.Paterson at 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
> > 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 at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries