<div dir="ltr"><a href="https://mail.haskell.org/pipermail/libraries/2015-January/024633.html">https://mail.haskell.org/pipermail/libraries/2015-January/024633.html</a><br><div><br></div><div>This has been raised before and rejected as it doesn't work.</div><div><br></div><div>The `Applicative` instance for `EitherT e m` does not have the same semantics as the Applicative for `Compose m (Either e)`.</div><div><br></div><div>Consider </div><div><br></div><div>foo <*> bar</div><div><br></div><div>foo = EitherT $ return $ Left "nope"</div><div>bar = throw "die die die"</div><div><br></div><div>If you foo 'fails', yielding Left e then EitherT e m a _stops_. It doesn't run the next action. On the other hand, `Compose m (Either e)` will run both foo and bar, then merge the answers. This is observably different if bar fails in a stronger way. e.g. if m itself is something like IO you can throw an exception in bar. The EitherT e IO instance will never execute bar, and never throw that exception.</div><div><br></div><div>These are different Applicatives for different types.</div><div><br></div><div>This issue has been repeatedly raised against transformers (at least once by me, once by David Feuer), and Ross has patiently corrected us each time. I figure it is my turn to pass along the received wisdom. ;)</div><div><br></div><div>The instance you request is only valid when 'm' has no notion of failure of its own, or no notion of observable side-effects. It doesn't work for m = IO. It doesn't work for m = Either f. In essence it isn't a valid instance for a Monad _transformer_, but rather it is only a valid instance for particular, well behaved, monads.</div><div><br></div><div>-Edward</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 12:02 PM, Nikita Volkov <span dir="ltr"><<a href="mailto:nikita.y.volkov@mail.ru" target="_blank">nikita.y.volkov@mail.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've recently discovered a flaw in the Applicative and Alternative instances of EitherT. I've posted the following pull request to fix them:<div><br></div><div><a href="https://github.com/ekmett/either/pull/38" target="_blank">https://github.com/ekmett/either/pull/38</a><br></div><div><br></div><div>The pull request contains the description of the problem.</div><div><br></div><div>ExceptT of "transformers" contains exactly the same flaw. However it's not hosted on GitHub, so I don't know a better place to report the issue then here.</div><div><br></div><div>Best regards,</div><div>Nikita Volkov</div></div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>