Proposal to solve the `EitherT` problem.

Edward Kmett ekmett at gmail.com
Wed Aug 14 16:51:01 CEST 2013


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130814/5b6817e7/attachment.htm>


More information about the Libraries mailing list