<div dir="ltr"><div>Like Maybe, Either has perfectly unambiguous semantics as a Monad as well. <div><br></div><div>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.</div>
</div><div><br></div><div>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.<br>
</div><div><br></div><div>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. </div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>-Edward</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 14, 2013 at 3:42 AM, Daniel Trstenjak <span dir="ltr"><<a href="mailto:daniel.trstenjak@gmail.com" target="_blank">daniel.trstenjak@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Tue, Aug 13, 2013 at 06:57:22PM -0400, Edward A Kmett wrote:<br>
> I look forward to finding out the new name for MaybeT then. ;)<br>
<br>
</div>That's a bit unfair, because the Maybe data type has a clear meaning<br>
which also holds for its Monad instance.<br>
<br>
That's not the case for Either. The Either data type doesn't propose<br>
a special meaning to the 'Left' or 'Right' case, but the Monad<br>
instance of Either does.<br>
<br>
Isn't just having a discussion about such a contradiction at the end<br>
the reason why Haskell is the language it is?<br>
<br>
<br>
Greetings,<br>
Daniel<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>