Proposal to solve the `EitherT` problem.

Gabriel Gonzalez gabriel439 at
Wed Aug 14 17:43:33 CEST 2013

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 

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:

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 <mailto:daniel.trstenjak at>> 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 <mailto:Libraries at>
> _______________________________________________
> Libraries mailing list
> Libraries at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list