Breaking Changes and Long Term Support Haskell

[Geoffrey Mainland]

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>> 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.

Geoff