<div dir="ltr">There is a lot of inertia for the convention to right-bias Either in Haskell. The Monad instance on Either is not going away anytime soon, so I think it only appropriate to have &quot;EitherT&quot; as its natural extension into transformer-land. Now if we *also* want to have an isomorphic type, for example ExceptionT e a = Exception e | NoExceptions a, and tell people that it is best practice to use *this* for error-handling code, then I see no problem with that. You could put something in the haddocks of EitherT about how exception-based programming should really be done with ExceptionT instead. But for discoverability&#39;s sake, for consistency&#39;s sake, I think that transformers is incomplete without EitherT.<div>

<br></div><div>The day Either loses its Monad instance, we can also throw away EitherT.<div><br></div></div></div><div class="gmail_extra"><br clear="all"><div>-- Dan Burton</div>
<br><br><div class="gmail_quote">On Wed, Aug 14, 2013 at 8:43 AM, Gabriel Gonzalez <span dir="ltr">&lt;<a href="mailto:gabriel439@gmail.com" target="_blank">gabriel439@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>I echo Edward&#39;s sentiments.  If you
      disagree with Edward&#39;s design choices then you should vote with
      your code instead of your +1&#39;s by building and actively
      maintaining libraries that uphold your design principles.<br>
      <br>
      I see all these hypothetical arguments that `Either` might cause
      somebody to accidentally use its monad instance once, ever, but
      let&#39;s consult the facts:<br>
      <br>
      * 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&#39;t actually care about this as much about
      this as they say they do.<br>
      <br>
      * Nobody has ever come onto Haskell cafe, Stack Overflow, or
      /r/haskell and asked: &quot;Where can I find an `Either` without the
      `Monad` instance?&quot;  This signals to me that most Haskell
      programmers don&#39;t actually want this &quot;feature&quot; as much as you say
      they do.<br>
      <br>
      * 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:<br>
      <br>
      <a href="http://packdeps.haskellers.com/reverse/errors" target="_blank">http://packdeps.haskellers.com/reverse/errors</a><br>
      <br>
      The reason Edward&#39;s libraries are popular and so widely used is
      because they solve an *actual* need, not a hypothetical need.<div><div class="h5"><br>
      <br>
      On 08/14/2013 07:51 AM, Edward Kmett wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      <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 &quot;;)&quot;
          as I was really just trying to use it to indicate that the
          &#39;consistency with the rest of transformers&#39; 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 &quot;State s&quot; be
          &quot;StateT s Identity&quot; 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&#39;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&#39;m just vociferously advocating for the least painful
          transition for me personally and tend to favor the &quot;don&#39;t
          rebikeshed&quot; solution over making changes for cosmetic reasons,
          because every single one of these &quot;lets standardize something
          from one of my packages but randomly rename it&quot; 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&#39;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">&lt;<a href="mailto:daniel.trstenjak@gmail.com" target="_blank">daniel.trstenjak@gmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div><br>
              On Tue, Aug 13, 2013 at 06:57:22PM -0400, Edward A Kmett
              wrote:<br>
              &gt; I look forward to finding out the new name for MaybeT
              then. ;)<br>
              <br>
            </div>
            That&#39;s a bit unfair, because the Maybe data type has a clear
            meaning<br>
            which also holds for its Monad instance.<br>
            <br>
            That&#39;s not the case for Either. The Either data type doesn&#39;t
            propose<br>
            a special meaning to the &#39;Left&#39; or &#39;Right&#39; case, but the
            Monad<br>
            instance of Either does.<br>
            <br>
            Isn&#39;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>
              <div><br>
                _______________________________________________<br>
                Libraries mailing list<br>
                <a href="mailto:Libraries@haskell.org" target="_blank">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>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Libraries mailing list
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<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>
<br></blockquote></div><br></div>