Proposal to solve the `EitherT` problem.

John Lato jwlato at gmail.com
Thu Aug 15 01:30:46 CEST 2013


Edward already pointed this out, however it seems to me that most
commenters on this thread are neglecting one salient point: transformers is
Ross's package.  I don't think anyone is presenting any new arguments at
this point, simply rehashing their support for one stance or another.
Given that, this appears to be devolving into "everyone respond on thread
until Ross caves," which I think is a bad precedent.


On Wed, Aug 14, 2013 at 6:03 PM, Gábor Lehel <illissius at gmail.com> wrote:

> +1 also, for what little it's worth.
>
> Maybe it would've been a better idea to have separate types for
> "asymmetric" error handling and for "symmetric" case-splitting in the
> first place, but we don't, we have Either. It has a Monad instance,
> and people use it. These ships have sailed. Consistency, simplicity,
> and the path of least resistance all point to lifting EitherT into
> transformers as it is. Bikeshedding the Best Possible Name for a new
> addition is one thing, but the potential benefit of renaming here
> would be so slight that it doesn't remotely justify breaking peoples'
> existing code over it.
>
> On Wed, Aug 14, 2013 at 5:43 PM, Gabriel Gonzalez <gabriel439 at gmail.com>
> wrote:
> > I echo Edward's sentiments.  If you disagree with Edward's design choices
> > then you should vote with your code instead of your +1's by building and
> > actively maintaining libraries that uphold your design principles.
> >
> > I see all these hypothetical arguments that `Either` might cause
> somebody to
> > accidentally use its monad instance once, ever, but let's consult the
> facts:
> >
> > * Nobody here has even lifted a finger to write up a library with this
> > hypothetical alternative to the `Either` without the `Monad` instance.
>  This
> > signals to me that the people arguing for removing the `Monad` instance
> > don't actually care about this as much about this as they say they do.
> >
> > * Nobody has ever come onto Haskell cafe, Stack Overflow, or /r/haskell
> and
> > asked: "Where can I find an `Either` without the `Monad` instance?"  This
> > signals to me that most Haskell programmers don't actually want this
> > "feature" as much as you say they do.
> >
> > * Lots of Haskell programmers use Either and EitherT fluently for error
> > handling without any confusion or programming mistakes.  My `errors`
> library
> > is proof of that:
> >
> > http://packdeps.haskellers.com/reverse/errors
> >
> > The reason Edward's libraries are popular and so widely used is because
> they
> > solve an *actual* need, not a hypothetical need.
> >
> >
> > On 08/14/2013 07:51 AM, Edward Kmett wrote:
> >
> > Like Maybe, Either has perfectly unambiguous semantics as a Monad as
> well.
> >
> > It is only when you muddle the waters with this fail nonsense that you
> need
> > to choose between the Either monad and the Error monad. Error and Either
> > would be indistinguishable otherwise.
> >
> > Re: unfair. I tried to take the sting out of it with a ";)" as I was
> really
> > just trying to use it to indicate that the 'consistency with the rest of
> > transformers' ship had sailed given that MaybeT exists and is within
> > transformers.
> >
> > 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.
> >
> > Ultimately, transformers is Ross's package, and the while maintainers can
> > poll and ask questions of the community and take the temperature of the
> room
> > it is fully his decision about how to move forward. Whatever he decides
> > goes.
> >
> > I'm just vociferously advocating for the least painful transition for me
> > personally and tend to favor the "don't rebikeshed" solution over making
> > changes for cosmetic reasons, because every single one of these "lets
> > standardize something from one of my packages but randomly rename it"
> > proposals induces a lot of accumulated work for me.
> >
> > I have come somewhat to dread the inevitable discussion when someone
> pops up
> > on the mailing list here asking to standardize something from one of my
> > packages. It seems it inevitably loses features, gets bikeshedded or
> > otherwise broken in such a way that creates work for me and others. I
> still
> > want to help with getting things out to a larger audience, but I prefer
> to
> > do so in a way that doesn't break code gratuitously, or worse force users
> > into a choice between the old and the new. However, that is wandering
> quite
> > a bit off topic.
> >
> > -Edward
> >
> >
> >
> > On Wed, Aug 14, 2013 at 3:42 AM, Daniel Trstenjak
> > <daniel.trstenjak at gmail.com> wrote:
> >>
> >>
> >> On Tue, Aug 13, 2013 at 06:57:22PM -0400, Edward A Kmett wrote:
> >> > I look forward to finding out the new name for MaybeT then. ;)
> >>
> >> That's a bit unfair, because the Maybe data type has a clear meaning
> >> which also holds for its Monad instance.
> >>
> >> That's not the case for Either. The Either data type doesn't propose
> >> a special meaning to the 'Left' or 'Right' case, but the Monad
> >> instance of Either does.
> >>
> >> Isn't just having a discussion about such a contradiction at the end
> >> the reason why Haskell is the language it is?
> >>
> >>
> >> Greetings,
> >> Daniel
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://www.haskell.org/mailman/listinfo/libraries
> >
> >
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
>
>
>
> --
> Your ship was destroyed in a monadic eruption.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130814/c702fc26/attachment.htm>


More information about the Libraries mailing list