<div dir="ltr"><div>On Sun, Oct 18, 2015 at 2:24 PM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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?</blockquote><div><br></div><div><div>There are three things entangled in your request that I'd like to uncouple.</div><div><br>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.<br><br>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.</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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.<br><br>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.</div><div><br></div><div>Again, none of the changes being proposed have any impacts before 8.2 (or even 8.4 at last check.)</div><div><div><br></div><div>-Edward</div></div></div></div></div></div>