[ghc-steering-committee] Stability

[Chris Dornan]

I liked it all the way down to GR3, which, for me, simply undermines GR1. Everybody who wants to make a breaking change has a good reason to make the change (at least in the minds of its adherents).

Chris

> On 22 Sep 2023, at 10:53, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> 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 <mailto: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 <mailto: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.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230922/f72c64d1/attachment.html>