[Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP
Yuras Shumovich
shumovichy at gmail.com
Sat Oct 10 20:12:11 UTC 2015
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.
More information about the Libraries
mailing list