<div dir="ltr"><div>I can give a couple of "rather academic" issues that the status quo causes:</div><div><br></div>An example of where this has bit us in the hindquarters in the past is that the old Error class based instance for Monad (Either a) from the mtl incurred a constraint on the entire Monad instance in order to support 'fail'.<div><br></div><div>This ruled out many applications for the Either monad, e.g. apo/gapo are based on the real (Either e) monad, just as para/zygo are based on the "real" ((,) e) comonad. This rather complicated the use of recursion schemes and in fact was what drove me to write what turned into the "either" package in the first place.</div><div><br></div><div>Now we don't try to support 'fail' at all for that Monad. Under this proposal though, one _could_ add a MonadFail instance that incurred a rather ad hoc constraint on the left hand side of the sum without encumbering the Monad itself.</div><div><br></div><div>In general you have no way of knowing that you stick to the product-like structure of the Monad in the current ecosystem, because 'fail' is always there, you can get to values in the Monad you couldn't reach with just return and (>>=). </div><div><br></div><div>Ideally you'd have (forall m. Monad m => m a) being isomorphic to a, this can be useful for ensuring we can plumb user-defined effects through code:</div><div><br></div><div><a href="http://comonad.com/reader/2011/searching-infinity/">http://comonad.com/reader/2011/searching-infinity/</a><br></div><div><br></div><div>but in Haskell as it exists today you always have to worry about it invoking a call to fail, and having a special form of _distinguishable_ bottom available from that computation so it is really more like `Either String a`.</div><div><br></div><div>Can you just say "don't do that?" </div><div><br></div><div>Sure, but it is the moral equivalent of programming with nulls all over your code.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 10, 2015 at 12:26 AM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@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 dir="ltr"><div class="gmail_extra">Thanks for putting this together.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The proposal says:</div><div class="gmail_extra"><br></div><div class="gmail_extra">"As a consequence, in current Haskell, you can not use Monad-polymorphic code safely, because although it claims to work for all Monads, it might just crash on you. This kind of implicit non-totality baked into the class is terrible."</div><div class="gmail_extra"><br></div><div class="gmail_extra">Is this actually a problem in practice? Is there any code we can point to that suffers because of the current state of affairs? Could it be included in the proposal?</div><div class="gmail_extra"><br></div></div>
<br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>