[Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

[Edward Kmett]

On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich <shumovichy at gmail.com>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151010/90bc7458/attachment.html>