[ghc-steering-committee] Stability

Sat Sep 23 04:15:37 UTC 2023

I have no problem at all with GR2, which covers the kind of unforeseen exceptional cases (3+4==>8, deep subsumption) we will need to be able to change.

My confusion comes in interpreting GR3 -- I gained the impression that GR1, GR2 and GR3 are describing the various constraints on the changes that can be made with GR3 stipulating that if you need to break GR1 then this should be done with deprecation cycles.

If GR3 is merely stipulating the way that GR2 changes should be rolled out (circumstances permitting) then I have no objection to GR3 at all -- except to suggest that it be tweaked to make it it explicit that it is elaborating on how GR2 changes should be deployed.

I have refrained from making any changes to the text until I am sure I understand what we wish to convey.

Chris

> On 22 Sep 2023, at 17:32, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
>> I have added a comment in the doc saying a bit more, but I strongly believe we have to forswear, ever, electively introducing breaking changes inside such a proposed stability framework. 
> 
> I feel I'm still misunderstanding you.
> 
> Are you really saying that if we discover that (3+4) returns 8 we should forswear, ever, fixing that bug?   (Fixing it is a breaking change.)   Surely not.  
> 
> To take a slightly less caricature example, are you saying that we should never have done simple subsumption, but forever adopted deep subsumption, accepting the semantic unsoundness and technical debt that we would thereby accumulate, forever.  Surely not?
> 
> I don't think I'm ready to forswear breaking (GR1).  But I agree that there should be a compelling reason.
> 
> Maybe when you say "we should qualify it sufficiently that it is never broken", you mean that (GR1) should say
> 
> General rule (GR1).  A stable Haskell program that works today should continue to work in subsequent releases of GHC, unless (GR2) applies.
> 
> Then, technically, breaking a stable program for a compelling reason doesn't break (GR1).  But that's a bit of distinction without a difference!
> 
> Simon
> 
> 
> 
> On Fri, 22 Sept 2023 at 16:58, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> I have added a comment in the doc saying a bit more, but I strongly believe we have to forswear, ever, electively introducing breaking changes inside such a proposed stability framework.
>> 
>> Something might happen to force us to make a change but such contingencies are covered by the current text.
>> 
>> Of course, experimental extensions can be subject to change, but this should, wherever possible, be done across deprecation cycles.
>> 
>> Any other changes will simply fall outside this framework and should have to be argued for as such.
>> 
>> I feel sure that we have enough tools at our disposal to make this work (see, for example, my suggestion for establishing #571 -Wsevere warnings as errors by default by capturing the behaviour in a language extension and rolling it into a future language standard).
>> 
>> Chris
>> 
>> 
>>> On 22 Sep 2023, at 13:08, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.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).
>>> 
>>> 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 <mailto: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 <mailto: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 <mailto: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/20230923/0eca6ad7/attachment.html>