<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
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. <br></div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I feel I'm still misunderstanding you.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Are you <i>really </i>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. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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?<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I don't think I'm ready to forswear breaking (GR1). But I agree that there should be a compelling reason.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Maybe when you say "we should qualify it sufficiently that it is never broken", you mean that (GR1) should say</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-left:40px" id="gmail-docs-internal-guid-e045ecba-7fff-dba6-19cb-ac2479d5607e"><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">General rule (GR1). A stable Haskell program that works today should continue to work in subsequent releases of GHC, <i>unless (GR2) applies</i>.</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br></span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Then, technically, breaking a stable program for a compelling reason doesn't break (GR1). But that's a bit of distinction without a difference!<br></span></p>
</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Sept 2023 at 16:58, 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 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 <<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"><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" target="_blank">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_-909908429405485081m_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_-909908429405485081m_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></div></blockquote></div>