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@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries



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