On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich wrote:

On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:

...

The part of the MRP proposal that I actively care about because it fixes a situation that *actually causes harm* is moving (>>) to the top level.

Sorry if I'm missing something, but moving (>>) is not part of the proposal. At least it is not mentioned on the wiki page:

https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn

Is the wiki outdated?

It arose during the original thread discussing the MRP but wasn't included in the 'proposal as written' that was sent out. https://mail.haskell.org/pipermail/libraries/2015-September/026129.html In many ways that proposal would do better 'on its own' than as part of the MRP.

return 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 pure 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.

So the cost of not moving `return` to the top level is zero?

For me the cost of moving it is pretty small, just an hour or two. Probably recompiling all the dependencies when switching to newer version of GHC will take longer. (Actually I'm still using 7.8 at work.) But the cost is definitely nonzero.

The proposal (as written on the wiki page) provides two arguments for the change:

There is no reason to include `return` into the next standard. That is true.

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. But we can leave `return` is `GHC` as a compiler specific extension for

backward compatibility, can't we?

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. 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. Could someone please clarify what is the cost of not moving `return` out of

`Monad`?

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. 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. 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. -Edward