Breaking Changes and Long Term Support Haskell

[Edward Kmett]

On Thu, Oct 22, 2015 at 12:20 PM, Mario Blažević <mblazevic at stilo.com>
wrote:

> On 15-10-22 09:29 AM, Geoffrey Mainland wrote:
>
>> ...
>>
>> 1) What is the master plan, and where is it documented, even if this
>> document is not up to the standard of a proposal? What is the final
>> target, and when might we expect it to be reached? What is in the
>> pipeline after MRP?
>>
>> Relatedly, guidance on how to write code now so that it will be
>> compatible with future changes helps mitigate the stability issue.
>>
>
>         I have been fully in favour of all the proposals implemented so
> far, and I think that having an explicit master plan would be a great idea.
> It would address some of the process-related objections that have been
> raised, and it would provide a fixed long-term target that would be much
> easier to make the whole community aware of and contribute to.
>
>         For that purpose, the master plan should be advertised directly on
> the front page of haskell.org. Once we have it settled and agreed, the
> purpose of the base-library commitee would essentially become to figure out
> the details like the timeline and code migration path. One thing they
> wouldn't need to worry about is whether anybody disagrees with their goals.
>
>
> 2) How can I write code that makes use of the Prelude so that it will
>> work with every new GHC release over the next 3 years? 5 years? For
>> example, how can I write a Monad instance now, knowing the changes that
>> are coming, so that the instance will work with every new GHC release
>> for the next 3 years? 5 years? If the answer is "you can't," then when
>> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
>> say I don't know the answer!
>>
>
>         From the discussions so far it appears that the answer for 3 years
> (or at least the next 3 GHC releases) would be to write the code that works
> with the current GHC and base, but this policy has not been codified
> anywhere yet. Knowing the upcoming changes doesn't help with making your
> code any more robust, and I think that's a shame. We could have a
> two-pronged policy:
>
> - code that works and compiles with the latest GHC with no *warnings* will
> continue to work and compile with no *errors* with the following 2
> releases, and
> - code that also follows the forward-compatibility recommendations current
> for that version of GHC will continue to work and compile with no *errors*
> with the following 4 releases.
>

We have adopted a "3 release policy" facing backwards, not forwards.
However, all proposals currently under discussion actually meet a stronger
condition, a 3 release policy that you can slide both forward and backwards
to pick the 3 releases you want to be compatible with without using CPP. It
also appears that all of the changes that we happen to have in the wings

https://ghc.haskell.org/trac/ghc/wiki/Status/BaseLibrary

comply with both of your goals here. However, I hesitate to say that we can
simultaneously meet this goal and the 3 release policy facing backwards
_and_ sufficient notification in all situations even ones we can't foresee
today. As a guideline? Sure. If we have two plans that can reach the same
end-goal and one complies and the other doesn't, I'd say we should favor
the plan that gives more notice and assurance. However, this also needs to
be tempered against the number of years folks suffer the pain of having in
an inconsistent intermediate state. (e.g. having generalized combinators in
Data.List today)

        The forward-compatibility recommendations would become a part of
> the online GHC documentation so nobody complains they didn't know about
> them. Personally, I'd prefer if the recommendations were built into the
> compiler itself as a new class of warnings, but then (a) some people would
> insist on turning them on together with -Werror and then complain when
> their builds break and (b) this would increase the pressure on GHC
> implementors.


The current discussion is centering around adding a -Wcompat flag that
warns of changes that you maybe can't yet implement in a way that would be
backwards compatible with a 3 release backwards-facing window, but which
will eventually cause issues.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20151022/84b9f50e/attachment.html>