<html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">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.<div><br></div><div>Something might happen to force us to make a change but such contingencies are covered by the current text.</div><div><br></div><div>Of course, experimental extensions can be subject to change, but this should, wherever possible, be done across deprecation cycles.</div><div><br></div><div>Any other changes will simply fall outside this framework and should have to be argued for as such.</div><div><br></div><div><div>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).</div><div><br></div><div>Chris</div><div><br></div><div><br><blockquote type="cite"><div>On 22 Sep 2023, at 13:08, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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).</blockquote><div><br></div><div>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?</div><div><br></div><div>Maybe you can rephrase (GR3)?</div><div><br></div><div>Simon<br></div><font color="#888888"><div><br></div></font>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Sept 2023 at 12:39, Chris Dornan <<a href="mailto:chris@chrisdornan.com">chris@chrisdornan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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).<div><br></div><div>Chris<br><div><br><blockquote type="cite"><div>On 22 Sep 2023, at 10:53, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Dear GHC SC</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">To avoid derailing <a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html" target="_blank">the debate about -Wsevere</a>, and <a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html" target="_blank">HasField redesign</a>, I'm starting a new (email for now) thread about stability.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I have tried to articulate what I believe is <a href="https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing" target="_blank">an evolving consensus in this document</a>.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Any views? You all have edit rights.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">========= Moritz's last email ============<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Now, this is derailing the original discussion a bit, and I'm not sure how far we want to take this. But, regarding <a class="gmail_plusreply" id="m_6972698572515480434m_-1388780740037794449plusReplyChip-0" href="mailto:marlowsd@gmail.com" target="_blank">@Simon Marlow</a>'s comment<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is one cultural aspect of our community I'd like to shift: the<br>expectation that it's OK to make breaking changes as long as you warn about<br>them or go through a migration cycle. It just isn't! (and I speak as<br>someone who used to make lots of changes, I'm now fully repentant!). That's<br>not to say that we shouldn't ever change anything, but when considering the<span><br>cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it<br>just defers it.</span></blockquote><div><br></div>I actually read this as we should stop having breaking changes to begin with. And _if_ we</div><div>do have breaking changes, that deprecation does not change the need to actually change</div><div>code (cost). As outlined in my reply to that, and <a class="gmail_plusreply" id="m_6972698572515480434m_-1388780740037794449plusReplyChip-2" href="mailto:lists@richarde.dev" target="_blank">@Richard Eisenberg</a>'s observation, it </div><div>"smears" the cost. The--to me--_much_ bigger implication of deprecation cycles is that we</div><div>_inform_ our _customers_ about upcoming changes _early_, instead of _after the fact_. We</div><div>also give them ample time to react. Being by changing their code, or raising their concerns.</div><div>Would the Simplified Subsumptions / Deep Subsumptions change have looked differently?</div><div>As such I see deprecation cycles as orthogonal to the question if we should have breaking</div><div>changes to begin with.</div><div><br></div><div>Thus I believe the following:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:tahoma,sans-serif">- Do have a deprecation cycle if possible.<br></span><span style="font-family:tahoma,sans-serif">- Do not treat a deprecation cycle as an excuse. Costs are deferred but are as large as ever.</span></blockquote><div><br></div><div>should be upgraded to:</div><div>- Preferably _no_ breaking changes.</div><div>- If breaking changes, then with a deprecation cycle, unless technically infeasible.</div><div>- An understanding that any breaking change incurs significant costs.</div><div><br></div><div>Ocaml recently added multicore support, and they put tremendous effort into making</div><div>sure it keeps backwards compatibility: <a href="https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md" target="_blank">https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md</a></div><div><span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:tahoma,sans-serif">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`.</span></blockquote><div><br></div></span><div>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.</div></div>
</div></div>
_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br></div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></body></html>