[ghc-steering-committee] Stability

[Simon Peyton Jones]

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