[ghc-steering-committee] Stability

[Simon Peyton Jones]

Dear GHC SC

To avoid derailing the debate about -Wsevere
<https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
and HasField redesign
<https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
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/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>
.

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 <marlowsd at gmail.com>'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
<lists at richarde.dev>'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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230922/3dd0e520/attachment.html>