<div dir="ltr"><div>I like it a lot! Did some minor editing and added a comment.</div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Sept 2023 at 10:54, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.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 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_-1166624482990934644m_-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_-1166624482990934644m_-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" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>