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?
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. But we can leave `return` is `GHC` as a compiler specific extension for backward compatibility, can't we? The second argument is `ApplicativeDo`, but I don't see the point. Breaking existing code "in order to benefit existing code" looks a bit strange. Could someone please clarify what is the cost of not moving `return` out of `Monad`? Sorry if it is already answered somewhere else, it is hard to find anything in such the huge email thread. Thanks, Yuras.