<div dir="ltr"><div>On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich <span dir="ltr"><<a href="mailto:shumovichy@gmail.com" target="_blank">shumovichy@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:<br>
> The part of the MRP proposal that I actively care about because it<br>
> fixes a<br>
</span>> situation that *actually causes harm* is moving (>>) to the top<br>
> level.<br>
<br>
Sorry if I'm missing something, but moving (>>) is not part of the<br>
proposal. At least it is not mentioned on the wiki page:<br>
<br>
<a href="https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn</a><br>
<br>
Is the wiki outdated?<span class=""><br></span></blockquote><div><br></div>It arose during the original thread discussing the MRP but wasn't included in the 'proposal as written' that was sent out.<div><br></div><div><a href="https://mail.haskell.org/pipermail/libraries/2015-September/026129.html">https://mail.haskell.org/pipermail/libraries/2015-September/026129.html</a><br></div><div><br></div><div>In many ways that proposal would do better 'on its own' than as part of the MRP.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> return itself lurking in the class doesn't matter to me all that much<br>
> as it<br>
> doesn't break anybody's asymptotics and it already has a sensible<br>
> definition in terms of pure as a default, so effectively you can<br>
> write code<br>
> as if MRP was already in effect today. It is a wart, but one that<br>
> could be<br>
> burned off on however long a time table we want if we choose to<br>
> proceed.<br>
<br>
</span>So the cost of not moving `return` to the top level is zero?<br>
<br>
For me the cost of moving it is pretty small, just an hour or two.<br>
Probably recompiling all the dependencies when switching to newer<br>
version of GHC will take longer. (Actually I'm still using 7.8 at<br>
work.) But the cost is definitely nonzero.<br>
<br>
The proposal (as written on the wiki page) provides two arguments for<br>
the change:<br>
<br>
There is no reason to include `return` into the next standard. That is<br>
true. </blockquote><div><br></div><div><div>Nobody is saying that we should remove return from the language. The proposal was to move it out of the class -- eventually. Potentially on a very very long time line.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">But we can leave `return` is `GHC` as a compiler specific extension for backward compatibility, can't we?<br></blockquote><div><br></div><div>This is effectively the status quo. There is a default definition of return in terms of pure today. The longer we wait the more tenable this proposal gets in many ways as fewer and fewer people start trying to support compilers versions below 7.10. Today isn't that day.</div><div><br></div><div>There are some niggling corner cases around viewing its continued existence as a compiler "extension" though, even just around the behavior when you import the class with Monad(..) you get more or less than you'd expect.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Could someone please clarify what is the cost of not moving `return` out of `Monad`?<br></blockquote><div><br></div><div>The cost of doing nothing is maintaining a completely redundant member inside the class for all time and an ever-so-slightly more expensive dictionaries for Monad, so retaining return in the class does no real harm operationally. </div><div><br></div><div>While I'm personally somewhat in favor of its eventual migration on correctness grounds and believe it'd be nice to be able to justify the state of the world as more than a series of historical accidents when I put on my libraries committee hat I have concerns. </div><div><br></div><div>I'm inclined to say at the least that IF we do decide to proceed on this, at least the return component should be on a long time horizon, with a clock tied to the release of a standard, say a Haskell2020. I stress IF, because I haven't had a chance to go through and do any sort of detailed tally or poll to get a sense of if there is a sufficient mandate. There is enough of a ruckus being raised that it is worth proceeding cautiously if we proceed at all.</div><div><br></div><div>-Edward</div></div></div></div>