[ghc-steering-committee] Stability

Dear GHC SC To avoid derailing the debate about -Wsevere https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003..., and HasField redesign https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003..., I'm starting a new (email for now) thread about stability. I have tried to articulate what I believe is an evolving consensus in this document https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47Zulga... . If we converge, we'll turn that into a proper PR for the GHC proposal process, although it has wider implications than just GHC proposals and we should share with a broader audience. But let's start with the steering committee. Any views? You all have edit rights. I think that the draft covers Moritz's and Julian's goals, at least that was my intention. I have pasted Moritz's last email below, for context. Simon ========= Moritz's last email ============ Now, this is derailing the original discussion a bit, and I'm not sure how far we want to take this. But, regarding @Simon Marlow 's comment This is one cultural aspect of our community I'd like to shift: the

expectation that it's OK to make breaking changes as long as you warn about them or go through a migration cycle. It just isn't! (and I speak as someone who used to make lots of changes, I'm now fully repentant!). That's not to say that we shouldn't ever change anything, but when considering the cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it just defers it.

I actually read this as we should stop having breaking changes to begin with. And _if_ we do have breaking changes, that deprecation does not change the need to actually change code (cost). As outlined in my reply to that, and @Richard Eisenberg 's observation, it "smears" the cost. The--to me--_much_ bigger implication of deprecation cycles is that we _inform_ our _customers_ about upcoming changes _early_, instead of _after the fact_. We also give them ample time to react. Being by changing their code, or raising their concerns. Would the Simplified Subsumptions / Deep Subsumptions change have looked differently? As such I see deprecation cycles as orthogonal to the question if we should have breaking changes to begin with. Thus I believe the following:

- Do have a deprecation cycle if possible. - Do not treat a deprecation cycle as an excuse. Costs are deferred but are as large as ever.

should be upgraded to: - Preferably _no_ breaking changes. - If breaking changes, then with a deprecation cycle, unless technically infeasible. - An understanding that any breaking change incurs significant costs. Ocaml recently added multicore support, and they put tremendous effort into making sure it keeps backwards compatibility: https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md PS: we should also agree that a "stable" extension should not require

dependencies on ghc-experimental. To become stable, any library support for an extension must move into `base`.

This seems like a good idea, however I still remain that _experimental_ features should not be on-by-default in a stable compiler. Yes, ideally I'd not even see them in a stable compiler, but I know this view is contentious. The use of `ghc-experimental` should therefore be guarded by `--std=experimental` as Julian suggested. That is a loud opt-in to experimental features.