<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 1:41 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 10/22/2015 01:29 PM, Edward Kmett wrote:<br>
> On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland<br>
</span><span class="">> <<a href="mailto:mainland@apeiron.net">mainland@apeiron.net</a> <mailto:<a href="mailto:mainland@apeiron.net">mainland@apeiron.net</a>>> wrote:<br>
><br>
><br>
>     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<br>
>     packages<br>
>     that themselves used the more modern Prelude.<br>
><br>
><br>
> It would definitely be a preferable state of affairs. Unfortunately,<br>
> at least with the tools available to us today, such a plan is<br>
> incompatible with any plan that introduces a new superclass. It also<br>
> cuts off plans that ever factors an existing class into two, such as<br>
> the MonadFail proposals. We simply do not at this time have the<br>
> technical capabilities that would support such a system. If they<br>
> showed up in GHC we can adapt plans to fit.<br>
<br>
</span>Great!<br>
<br>
Could we work to characterize what technical capabilities we would need<br>
to support full backwards Prelude compatibility?<br>
<br>
Here is my rough understanding of what we would need:<br>
<br>
1) Some method for "default superclasses." This would solve the AMP issue.<br>
<br>
2) A method for factoring existing classes into two (or more) parts.<br>
This would solve the MonadFail problem.<br>
<br>
3) A method for imposing extra superclass constraints on a class. This<br>
would be needed for full Num compatibility. Seems much less important<br>
that 1 and 2.<br>
<br>
The most thought has gone into 1.<br></blockquote><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"><br>
Are these three technical capabilities *all* that we would need? Perhaps<br>
we also need a way to tie the current language (-XHaskell98,<br>
-XHaskell2010) to a particular implementation of the Prelude.<br></blockquote><div> <br></div><div><div>I don't have a concrete plan here. I'm not even sure one can be achieved that works. I'd say that the burden of figuring out such a thing falls on the party that can create a plan, pitch it to the community and potentially implement it.</div></div><div><br></div><div>If I enumerate a set of conditions here I'm basically implying that I'd agree to any plan that incorporated them. I'm just not prepared to make that commitment sight-unseen to something with unknown warts and implications.</div><div><br></div><div>I can, however, say that it is plausible that what you have enumerated above could potentially address the outstanding issues, but I don't know how good of a compromise the result would be. </div><div><br></div><div>-Edward</div></div></div></div>