<br><div class="gmail_quote">On Tue, May 25, 2010 at 2:32 PM, Henning Thielemann <span dir="ltr">&lt;<a href="mailto:schlepptop@henning-thielemann.de">schlepptop@henning-thielemann.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Isaac Dupree schrieb:<br>
<div class="im">&gt; Assuming we do want to keep Either having a Monad instance at all, we do<br>
&gt; as Ross says have to pick the &quot;leftmost error&quot; rather than &quot;all errors&quot;<br>
&gt; Applicative instance.  (Monad cannot produce errors beyond the leftmost,<br>
&gt; due to its later-actions-depend-on-results-from-earlier-ones nature.)<br>
<br>
</div>I can live without the Monad Either instance.<br>
<div><div></div><div class="h5"></div></div></blockquote><div><br>I too would be much happier if the current Monad Either instance were to
 vanish from mtl/transformers/monads-(fd/tf) as the annoying Error constraint breaks a
 number of wonderful theoretical properties.<br><br>In my perfect world the next version of transformers would provide an entry in Control.Monad.Instances for:<br><br>instance Applicative (Either m)<br>instance Alternative (Either m) <br>

instance Monad (Either m)<br>
instance MonadPlus (Either m)<br>
<br>
of which the instance for Applicative could be pushed up to Control.Applicative as part of this proposal, with Alternative making the move later and then Control.Monad.Error could follow suit with the way State, Reader and Writer are being redefined as type aliases of their transformers wrapped around identity, ditching the Either instance in favor of ErrorT e Identity for symmetry. Sadly, the class used by Control.Monad.Error is named Error, 
robbing us of the obvious name for the type alias.<br>
<br>That said it would break a fair 
amount of existing code, and is a separate issue pertaining to a 
separate library and so should probably be considered on its own merits 
in another proposal as anything that relied on importing 
Control.Monad.Error and being able to 
then do [ x | Right x &lt;- xs ] would break.<br><br>But there are quite possibly too many moving parts to make such a big jump, and then you have the other bikeshedding issue of there being yet another definition for Either that makes sense to default to:<br>
<br>instance Monoid m =&gt; Applicative (Either m)<br>
instance Monoid m =&gt; Alternative (Either m) <br>

instance Monoid m =&gt; Monad (Either m)<br>

instance Monoid m =&gt; MonadPlus (Either m)<br><br>which would likely ensure that any such concrete proposal wings up stillborn.<br><br>The former monad is nice for things like implementing generalized apomorphisms as generalized anamorphisms, for symmetry with implementing zygomorphisms (generalized paramorphisms) as generalized catamorphisms, the latter has less theoretical appeal but it is still easy to remember, convenient to use, and has a pseudo-symmetric relationship to Monoid m =&gt; Monad ((,) m).<br>
<br>-Edward Kmett<br></div></div>