<div dir="ltr">The part of the MRP proposal that I actively care about because it fixes a situation that <b>actually causes harm</b> is moving (>>) to the top level.<div><br></div><div>Why?</div><div><br></div><div>Right now <font face="monospace, monospace">(*>)</font> and <font face="monospace, monospace">(>>)</font> have different default definitions. This means that code runs often with different asymptotics depending on which one you pick. Folks often define one but not the other.</div><div><br></div><div>This means that the performance of <font face="monospace, monospace">mapM_</font> and <font face="monospace, monospace">traverse_</font> needlessly differ. It means that we can't simply weaken the type constraint on <font face="monospace, monospace">mapM_ </font>and <font face="monospace, monospace">sequence_</font> to <font face="monospace, monospace">Applicative</font>, it as a knock-on consequence it means we can't migrate mapM and sequence out of Traversable to top level definitions and thereby simply provide folks with more efficient parallelizable mapping when they reach for the 'obvious tool'.</div><div><br></div><div><font face="monospace, monospace">return</font> itself lurking in the class doesn't matter to me all that much as it doesn't break anybody's asymptotics and it already has a sensible definition in terms of <font face="monospace, monospace">pure</font> as a default, so effectively you can write code as if MRP was already in effect today. It is a wart, but one that could be burned off on however long a time table we want if we choose to proceed.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 7, 2015 at 5:13 PM, Mark Lentczner <span dir="ltr"><<a href="mailto:mark.lentczner@gmail.com" target="_blank">mark.lentczner@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"><span class=""><br><div class="gmail_quote">On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink <span dir="ltr"><<a href="mailto:hesselink@gmail.com" target="_blank">hesselink@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 style="overflow:hidden">While I don't think it detracts from your argument, it seems you<br>
misread the original proposal. At no point will it remove `return`<br>
completely. It would be moved out of the `Monad` class and be made<br>
into a top-level definition instead, so you would still be able to use<br>
it.<div><div></div></div></div></blockquote></div><br></span>Then why bother?</div><div class="gmail_extra">If you don't intend to regard code that uses "return" as old, out-dated, in need of updating, etc....</div><div class="gmail_extra">If you don't intend to correct people on #haskell to use pure instead of return...</div><div class="gmail_extra">If you don't tsk tsk all mentions of it in books.... </div><div class="gmail_extra">If you don't intend to actually deprecate it.</div><div class="gmail_extra">Why bother?</div><div class="gmail_extra"><br></div><div class="gmail_extra">But seriously, why do you think that "you would still be able to use it"? That is true for only the simplest of code - and untrue for anyone who has a library that defines a Monad - or anyone who has a library that they want to keep "up to date". Do you really want to have a library where all your "how to use this" code has return in the examples? Shouldn't now be pure? Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown in Hackage? This is just a nightmare for a huge number of libraries, and especially many commonly used ones.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Why bother!</div><div class="gmail_extra"><br></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" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>