[ghc-steering-committee] Stability

[Simon Peyton Jones]

>
> 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).


Can you elaborate? I don't understand.  GR3 says simply "if you have a
compelling (GR2) reason to break (GR1) then do whatever you can to mitigate
the impact via a deprecation cycle".  Why does that undermine GR1?

Maybe you can rephrase (GR3)?

Simon


On Fri, 22 Sept 2023 at 12:39, Chris Dornan <chris at chrisdornan.com> wrote:

> 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
> <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.
> _______________________________________________
> 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/d07cb1c1/attachment-0001.html>