Breaking Changes and Long Term Support Haskell

[Bardur Arantsson]

On 10/22/2015 07:41 PM, Geoffrey Mainland 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>> 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?
> 

It's basically the stuff that never materialized in 10 years until
people got fed up with the situation and voted AMP through even though
it would cause (limited) breakage.

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

You say "all" as if a) it's easy (hint: it's all highly non-trivial), b)
anybody's actually going to do the work.

Look, we'd all like unicorns and rainbows, but clearly nobody's done the
required work[1], and a lot of people were getting fed up with the
status quo.

Just wishing that this will happen won't make it so, and frankly,
downplaying the difficulty seems like an attempt to veto any change.

Regards,

[1] Understandable, given the highly non-trivial nature of it.