Breaking Changes and Long Term Support Haskell

[Geoffrey Mainland]

On 10/22/2015 02:25 PM, Edward Kmett wrote:
>
> On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland
> <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
>
>     On 10/22/2015 01:29 PM, Edward Kmett wrote:
>     > On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland
>     > <mainland at apeiron.net <mailto:mainland at apeiron.net>
>     <mailto:mainland at apeiron.net <mailto:mainland at apeiron.net>>> wrote:
>     >
>     >
>     >     I am not against changing the Prelude! But it sure would be
>     nice if
>     >     -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010
>     gave me a
>     >     Haskell 2010 Prelude, both of which could be used with external
>     >     packages
>     >     that themselves used the more modern Prelude.
>     >
>     >
>     > 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.
>
>     Great!
>
>     Could we work to characterize what technical capabilities we would
>     need
>     to support full backwards Prelude compatibility?
>
>     Here is my rough understanding of what we would need:
>
>     1) Some method for "default superclasses." This would solve the
>     AMP issue.
>
>     2) A method for factoring existing classes into two (or more) parts.
>     This would solve the MonadFail problem.
>
>     3) A method for imposing extra superclass constraints on a class. This
>     would be needed for full Num compatibility. Seems much less important
>     that 1 and 2.
>
>     The most thought has gone into 1.
>
>
>     Are these three technical capabilities *all* that we would need?
>     Perhaps
>     we also need a way to tie the current language (-XHaskell98,
>     -XHaskell2010) to a particular implementation of the Prelude.
>
>  
> 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.
>
> 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.
>
> 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. 
>
> -Edward

I don't have a concrete plan either, not am I sure that one is possible.
But I don't see how having a conversation about how one might achieve
backwards compatibility would commit anyone to anything. Any eventual
proposal would have to go through the same approval process as every
other proposal. And even if we did have a hypothetical draft proposal
that you had at some point stated you approved of in some way, you would
always be free to change your mind!

Isn't the libraries list exactly where this sort of conversation should
happen?

Cheers,
Geoff