Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Edward Kmett]

On Sun, Oct 18, 2015 at 2:24 PM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

> Btw. there were proposals of GHC extensions that allow class hierarchy
> updates without much code breakage (class aliases) etc. Could we defer the
> MRP until such extensions are implemented?


There are three things entangled in your request that I'd like to uncouple.

1.) None of those proposals would actually have any impact here: `pure` is
already a member of Applicative that people already define. `return`
already has a definition in terms of `pure` as its default.

2.) This proposal is definitely being deferred in one sense, nothing can
even happen on the warning front until 8.2 at the earliest under the "3
Release Policy" and in practice we'd probably push it back further still
given the scope. So you have a couple of years before you'd even hear a
peep from the compiler about this saying that hey maybe you might want to
consider doing something.

3.) Finally, it isn't clear to me that we're going to be able to achieve a
meaningful consensus on how to proceed with superclass defaults. We've been
tossing proposals for them around for years. There are at least 3 of them
in the wings, with both Richard Eisenberg and Conor McBride having
different proposals that yield different end states with varying degrees of
prescriptiveness about how they should be used, and some other folks who
disbelieve it can be implemented at all in a way that works well with
anything more complicated than a linear chain of instances.

So while they don't apply to this item, I'm hesitant to incur such a
proposal as a blocker on anything when there is no sign of termination in
sight and no indication of which way that feature will break in terms of
supplied functionality.

That is a broader statement as while here they bring nothing to the table
that would affect code written under this proposal, elsewhere they could
help. -- If we had them at most eventually people would be able to consider
(maybe) dropping the manual declaration of Functor, and possibly inline
some of their definitions from Applicative into the Monad declaration
(depending on which proposal wins favor if any, and if that version of the
proposal always complains when it is used like Richard's variant), but the
story of pure vs. return doesn't change meaningfully.

That said, if a version of the feature showed up over the next 2-3 years in
GHC, we'd likely modify the Monoid-Semigroup Proposal to incorporate it as
that proposal could benefit, but as above I'd hesitate to tie anything to
the fate of a superclass default proposal.

Again, none of the changes being proposed have any impacts before 8.2 (or
even 8.4 at last check.)

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151019/637af781/attachment.html>