GHC stability

ghc-stability.md

Nobody wants this:

Nobody wants to block changes to GHC. It is deep in Haskeller culture that we do not accept stagnation. We refactor. We refactor our language, its libraries and our projects — it is one of the key benefits of strong-typing.

Some of us think this is important

We want a process for managing changes to GHC and Haskell. We want this because:

• We see how unstructured changes are leading to frustration and discord, especially with those outside of the GHC development processes but responsible for various kinds of insfrastructure, especially packages.
• A better framework for managing change will allow us to carry out the changes we need to more easily without low-level interpersonal conflict across the community.

Psychological factors are key

If you are responsible for maintaining community ifrastructure in your limited and prescious spare time it is just so unwelcome to have users of your wares wanting to know when you will fix your stuff for the latest infrastructure update. It is quite possible that this will come as a surprise and it will often be quite difficult to appreciate why this disruption was necessary.

Developers feel strongly that the various forces in charge of Haskell infrastructure have been careless about this in the past. (A quite innocuous enquiry about tidying up Eq led to quite the pushback on social media prompting some of us to set up the Haskell Stability Group.)

The key thing here is the feeling widely held by package maintainers that you are exposed to the whims of various groups in charge of key Haskell infrastructure, with a seriously high-handed attitude that they know what is best for the long term future of Haskell and are pretty indifferent to the pain and frustration they are causing downstream.

It is the lack of control that is key here — there is no process here, just being hostage to the whims of self-appointed groups changing stuff without much by way of an agreed process.

(And note that I am saying that this is a widely held perception; whether it is fair or not is less important than identifying actions that will change this perception.)

An Example

Some time back I realised that PolyKinds was breaking a key pattern that I was relying on in multiple code bases and made sure to not enable it. This then bit me when I switched to GHC-9.2 as that enables GHC2021 by default. I wrote this up at the time here. My arrival in this group somewhat overlapped with the GHC2021 initiative so I had no say in its original inclusion but I was surprised to see how easiy folks just pressed ahead with including a significan breaking change in the default configuration of the compiler. (This has bitten others — see this thread where a developer admits ragequitting Haskell 'despite the language being beautiful').

But at least there was action I could take to protect myself — I could ensure that all of my source code asserted Haskell2010 at the top of the module.

Why A Framework is Needed

Having a framework and agreed processes is key — it isn't enough to say 'trust us, we know best and we will endeavour to only break your stuff when we think it is important, or when we think it won't break very much of you stuff anyway'. Folks want reassurance that there are processes in place and that they can opt-in to potentially disruptive changes on their own schedule. Those that want all the good stuff ASAP can make use of the amazing turnover of GHC compilers (it really is a wonder to behold) while those that just need to know what process they can upgrade with confidence and feed in changes when they are ready.

I think we can lean on the GHC20XX mechanism to feed many disruptive changes in a way that should allow us to make those changes relatively easily while allowing those that want high levels of control over when they feed those changes into their setups. I think you will find that people will be quite acceptiing of our changes once they have understood that we are following an agreed process that gives them control over when they activate them.

One more thing

Please hang those changes on extensions whenever feasible.

• Extensions act as tags making it each to chase down release notes, blog articles, etc. This is not a small issue.
• Keeping GHC20XX a simple shorthand for enabling extesions is a really clean structure nad helps to keep everything nice and modular.

Please can we hang the proposed change of behaviour on an extension.

but I was surprised to see how easiy folks just pressed ahead with including a significan breaking change in the default configuration of the compiler

I don't remember specifically discussing PolyKinds, but we did discuss the impact of changing the default language standard at the time. IIRC the argument (which I agree with) was that production codebases should be expected to set the preferred standard, e.g. default-language: Haskell2010 in your .cabal file. So the impact of changing GHC's default should be limited to small, one-off scripts and scratchpads.

A similar argument is made in Simon's Stability Policy:

We define a stable Haskell package as follows ... Explicitly specifies a language edition (Haskell98, GHC2021), in the source code or the build configuration

@gridaphobe I think this is something that needs to be spelt out loudly and explicitly in every introductory material. It should be spelt out (and likely produce a warning if not, that explains not only that it's missing, but also why it is important to have one) that the default-language can change with GHC releases, as the language evolves?

@gridaphobe i am now fully on board with switching the default language — at the time it came as a surprise, which underlines Moritz’s point about the importance of comms.

I agree 100% that this needs to be signaled loud and clear. I think it would even be reasonable for Hackage to reject packages that do not specify a default-language, much like it rejects packages that specify -Werror.

No liked on gists 😔 proposing hackage rejects packages without default-language sounds like a good idea!