<div dir="ltr">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="plusReplyChip-0" href="mailto:marlowsd@gmail.com" tabindex="-1">@Simon Marlow</a>'s comment<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color: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<br>cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it<br>just defers it.</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="plusReplyChip-2" href="mailto:lists@richarde.dev" tabindex="-1">@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-width:1px;border-left-style:solid;border-left-color: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">https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md</a></div><div><br class="gmail-Apple-interchange-newline"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color: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><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><br></div></div><div>Best,</div><div> Moritz</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Sept 2023 at 16:33, 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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
The General Rules outlined in <a href="https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305</a> can be a good first step. </blockquote><div><br></div><div>I think that articulating some General Rules like this would help us a lot.</div><div><br></div><div>If we had <a href="https://github.com/ghc-proposals/ghc-proposals/pull/601" target="_blank">#601 </a>in some form (it is back with the author for review), we would have a list of extensions designated "stable", which we might treat differently to extensions designated "experimental". That would help too.</div><div><br></div><div>I realise that (GR1) is stronger than I intended: I think we need to allow room to modify extensions designated "experimental" -- that's what "experimental" means! <br></div><div></div><div>
<ul><li>General rule (GR1): a GHC proposal should ensure that code that invokes only extensions designated "stable", and that compiles before the change, will continue compile
after the change, given the same compiler flags</li><ul><li>We exclude <code>-Werror</code> because otherwise (GR1) would be broken whenever we add a warning.</li><li>We exclude experimental extensions because those are (by definition) subject to change.</li><li>(GR1) is trivially satisfied if the change is gated behind an extension flag.</li><li>(GR1) is broken if, say, we turn a warning into an error</li></ul></ul><div>Is that acceptable? <br></div><div><br></div><div>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`.<br></div><div><br></div><div>Moritz quotes Simon M saying <br></div><div><br></div><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">when considering the cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it just defers it.</blockquote><div><br></div><div>I understood that as saying "don't bother with a deprecation cycle". But I understand Moritz as saying "please give us a deprecation cycle". I don't have a strong view myself but it would be good to achieve consensus on this point. I <i>think </i>(but I am not sure) that the consensus is:</div><div><ul><li>Do have a deprecation cycle if possible.</li><li>Do not treat a deprecation cycle as an excuse. Costs are deferred but are as large as ever.</li></ul><div>Simon<br></div></div>
</div></div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Sept 2023 at 09:13, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:tahoma,sans-serif" class="gmail_default"></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:tahoma,sans-serif" class="gmail_default"></div></div></blockquote><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:tahoma,sans-serif" class="gmail_default"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex;font-family:tahoma,sans-serif"><div dir="auto" style="font-family:tahoma,sans-serif">As there is supposedly a backwards compatible implementation for this, I’d like to ask for this to be considered in two steps:</div><div dir="auto" style="font-family:tahoma,sans-serif">- backwards compatible change first.</div><div dir="auto" style="font-family:tahoma,sans-serif">- deprecation and change of syntax second.</div></blockquote><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">If that's possible, it sounds plausible. Perhaps you can make the suggestion on the main discussion thread, and Adam can respond? <br></div></div></div><div dir="ltr"><div style="font-family:tahoma,sans-serif" class="gmail_default"><span></span></div></div></blockquote><div dir="auto"><br></div><div dir="auto">The proposal already contains this suggestion if my reading is correct. The breaking change is the reordering of parameters of setField. And lists under the section “Order of arguments to setField”, that this proposal can work without the reordering.</div><div dir="auto"><br></div><div dir="auto">I am feeling quit uneasy arguing for this, as this option only came up due to the proposal being written so thoroughly. The proposal also explicitly notes that OverloadedRecordUpdate has been marked as experimental. In the “Backward Compatibility” section. </div><div dir="auto"><br></div><div dir="auto">While I still disagree that there can be any experimental features in a stable release, I can see myself supporting this proposal if we collectively work towards preventing this going forward. The General Rules outlined in <div dir="auto"><a href="https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305</a> can be a good first step. </div><div dir="auto"><br></div><div dir="auto">I’d still like to hear Simon Marlow’s thoughts on this after his plea for a culture shift recently<div><a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html" target="_blank">https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html</a></div></div></div><div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto"> Moritz</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:tahoma,sans-serif" class="gmail_default" dir="auto"><span>On Fri, 22 Sept 2023 at 02:07, Moritz Angermann <</span><a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@gmail.com</a><span>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto">I’m tempted to recuse myself as well on the technical merits of this proposal. As others might already expect, I am concerned about this breaking existing code. Do we have a rough estimate how much this will break?</div><div dir="auto"><br></div><div dir="auto">It also surfaces a topic we discussed just a short while ago. We have a feature in a stable compiler release, which we consider experimental, and thus reserve the right to break? I find this concept still fundamentally flawed. Anything that is part of stable compiler releases has to be considered stable by extension and thus needs to be treated with utmost care.</div><div dir="auto"><br></div><div dir="auto">I can see and fully support the wish to have a language reactor where things can be experimented with. But if we have this in our stable releases, it needs to be guarded in a way that users of those features have to actively opt in to it. I have people seen adopting this feature already, and I do not believe all of them are aware that this is a bleeding edge feature that can break without notice at any point in time.</div><div dir="auto"><br></div><div dir="auto">As there is supposedly a backwards compatible implementation for this, I’d like to ask for this to be considered in two steps:</div><div dir="auto">- backwards compatible change first.</div><div dir="auto">- deprecation and change of syntax second.</div><div dir="auto"><br></div><div dir="auto">Yes, this will be more work on behalf of the implementors. The burden of change is on the implementors, we can’t expect our users to cover the costs.</div><div dir="auto"><br></div><div dir="auto">For the second part, we should also have a thorough justification for the need to break. </div><div dir="auto"><br></div><div dir="auto">I’ll leave this with two links:</div><div dir="auto">Simon Marlow’s recent comment: <div><a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html" target="_blank">https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html</a></div><div dir="auto">Dimitriis Tweet contrasting OCaml to Haskell: <div><a href="https://x.com/chshersh/status/1704886633856696831?s=46" target="_blank">https://x.com/chshersh/status/1704886633856696831?s=46</a></div></div></div><div dir="auto"><br></div><div dir="auto">Best</div><div dir="auto"> Moritz</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Sep 2023 at 1:21 AM, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Am Donnerstag, dem 21.09.2023 um 09:37 +0200 schrieb Arnaud Spiwack:<br>
> Dear all.<br>
> <br>
> I submitted my recommendation 3 weeks ago, and only Simon has<br>
> commented yet. Please let me know your thoughts.<br>
<br>
I am essentially ignorant about anything related to records in Haskell,<br>
and will recuse myself, trusting y’all about this.<br>
<br>
Cheers,<br>
Joachim<br>
<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<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></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>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>