<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland <span dir="ltr"><<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
>     I outlined one possible path to avoid this kind of issue: spend more<br>
>     time thinking about ways to maintain compatibility. We had<br>
>     proposals for<br>
>     doing this with AMP.<br>
><br>
><br>
> And on the other hand we also had a concrete proposal that didn't<br>
> require language changes that was ridiculously popular. People had<br>
> been talking about Applicative as a superclass of Monad for a decade<br>
> before we finally acted upon the AMP. People had been talking about<br>
> superclass defaulting for a decade. When do you cut off discussion and<br>
> ship the proposal that has overwhelming support? If there is no<br>
> process that enables this you can stall the process indefinitely by<br>
> raising objections of this form. Such a situation is not without costs<br>
> all its own.<br>
><br>
<br>
</span>I agree. It was certainly within the power of the committee to start a<br>
clock and say something like "if we don't have a patch to GHC that<br>
provides backwards compatibility for AMP within 1 year, we will push out<br>
AMP as-is." Had I understand the implications of AMP at the time, or<br>
even been aware that AMP was happening (I was actually actively working<br>
on the GHC code base during that period), that certainly would have been<br>
motivation for me to do something about it! *That* would be how one<br>
could cut off discussion and ship a proposal.<br></blockquote><div><br></div><div>I freely admit that there is room for improvement in the process. We're all learning here.</div><div><br></div><div>The current Semigroup-Monoid proposal more or less fits the bill you are looking for here. We have a roadmap today that migrates an existing package with several years worth of back support into base more or less unmodified, and then in 3 releases starts requiring instances. You can think of that 3 release clock as precisely what you are looking for here.</div><div><br></div><div>If we get an implementation of superclass defaulting or some other mechanism that can mitigate the extra couple of lines of code that this proposal will tax users with, within that timeline, we'd gladly incorporate it into the proposal.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am not against changing the Prelude! But it sure would be nice if<br>
-XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a<br>
Haskell 2010 Prelude, both of which could be used with external packages<br>
that themselves used the more modern Prelude. </blockquote><div><br></div><div>It would definitely be a preferable state of affairs. Unfortunately, at least with the tools available to us today, such a plan is incompatible with any plan that introduces a new superclass. It also cuts off plans that ever factors an existing class into two, such as the MonadFail proposals. We simply do not at this time have the technical capabilities that would support such a system. If they showed up in GHC we can adapt plans to fit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe that's impossible.<br>
Setting a firm deadline to finding a solution to the compatibility issue<br>
would have been a way to compromise. Ideally, changing the Prelude<br>
wouldn't require breaking code written to use an older version of the<br>
Prelude. Yes, attaining that goal would require more work.<br></blockquote><div><br></div><div>We looked around for a year for a roadmap that would get us there. None presented itself. In the end we wound up shedding the core libraries status of the haskell98 and haskell2010 packages as the 3-4 different ways in which one could write a Haskell2010 package all have different trade-offs and can be maintained in user-land.</div><div><br></div><div>Examples:</div><div><br></div><div>* A hardline version of haskell2010 with a Monad and Num that fully complies with the report, but which doesn't work with Monad and Num instances supplied by other libraries. This needs RebindableSyntax, so it doesn't quite work right. With compiler support for rebinding syntax to a particular library instead of to whatever is in scope, such a thing might be suitable for teaching a Haskell class.</div><div><br></div><div>* A pragmatic haskell2010 where the Monad has an Applicative superclass and Num has the current semantic. This works with everything but doesn't faithfully follow the report. </div><div><br></div><div>*  A middle-ground package that tries to use a superclass defaulting mechanism that we don't have to supply missing Applicative superclasses might resolve the Applicative-Monad issue in theory, but does nothing for report compliance of our existing Num.</div><div><br></div><div>Each one of these solutions has flaws. Two of them require innovations in the compiler that we don't have.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Evolving the Prelude and maintaining compatibility are not necessarily<br>
mutually exclusive options.<br></blockquote><div><br></div><div>Agreed, but as you can see above, maintaining compatibility isn't necessarily always a viable option either.</div><div><br></div><div>-Edward</div></div></div></div>