<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">OK so concretely you are saying</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>Expressing support for the general rules in the <a href="https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing">draft GHC stability policy</a>.</li><li>Advocating for a deprecation cycle for this specific -Wsevere proposal, rather than introducing it immediately. <br></li></ul><div>OK now I understand.</div><div><br></div><div>Moreover, you add</div><div><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>
My favoured solution is to predicate this new behaviour on a language extension and incorporate that into GHC2024
</div></blockquote><div><br></div><div>I'm not quite sure what you mean here. I think that you could be saying:</div><div><ul><li>Do not add -Wsevere</li><li>Instead add an extension -XMissingMethods, on by default.</li><li>At some point, after a deprecation cycle, make -XNoMissingMethods become the default.</li><li>-Wwarn=missing-methods would be unaffected; but would become redundant with -XNoMissingMethods.<br></li></ul> and follow the same pattern for missing-fields.</div><div><br></div><div>That is, you want to address <a href="https://github.com/ghc-proposals/ghc-proposals/issues/615">https://github.com/ghc-proposals/ghc-proposals/issues/615</a> by doubling down on language extensions, rather than by bigging-up warning flags. <br></div><div><br></div><div>Do I have that correct? Perhaps you can make the case on that discussion thread?</div><div><br></div><div>Simon<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 9 Oct 2023 at 09:45, 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>When I refer to `the framework` I was thinking of the <i>GHC Stability Policy</i> document that you created (where we try not to introduce breaking changes, but when we do we use deprecation cycles unless there is a good reason not to).<div><br></div><div>My favoured solution is to predicate this new behaviour on a language extension and incorporate that into GHC2024 -- that could be done using established mechanisms -- but my overriding concern is that the changes in behaviour be fitted into the framework for introducing breaking changes that we have been discussing these past few weeks in the <i style="color:rgb(0,0,0)">GHC Stability Policy</i><span style="color:rgb(0,0,0)"> document.</span><br><div><br></div><div>The key to me is that it be fitted into an agreed policy for making breaking changes, not that it adhere to my particular preferences, or the state of a particular proposal under discussion -- hence my somewhat abstract choice of terms.</div><div><br></div><div>Is that clear? I don't want to prescribe here (though I have preferences) but please give me something that could <span style="color:rgb(0,0,0)">plausibly</span><span style="color:rgb(0,0,0)"> </span>be part of a general policy for introducing breaking changes moving forward.</div><div><br></div><div>Chris<br><div><div><br><blockquote type="cite"><div>On 9 Oct 2023, at 09:09, 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"><div>I remain opposed to this proposal in its current form, at least
until I can understand why the changes have to be made outside of the
framework for change we are trying to establish.</div></blockquote><div><br></div><div>Chris, can you just lay out "the framework for change we are trying to establish"? I accept the importance of the considerations you describe, in this email and in your gist. So I understand what you are arguing <b>against</b>; but I don't yet see what you are arguing <b>for</b>.</div><div><br></div><div>It's hard to argue against "a framework that will remove a lot of friction in making changes, and
also remove key stressors from all those maintaining the critical
infrastructure outside of the core tools that make Haskell truly viable
for real-world development". But what, precisely, do you have in mind?
</div><div><br></div><div>And in the context of this specific proposal, what are you arguing for?</div><div><br></div><div>Thanks. Sorry to be dim.</div><div><br></div><div>Simon<br></div><div> <br></div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 8 Oct 2023 at 19:12, 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><h2 id="m_-5477807753120134477m_-4638893244173265673user-content-nobody-wants-this" style="box-sizing:border-box;margin-bottom:16px;line-height:1.25;padding-bottom:0.3em;color:rgb(16,25,32);font-family:-apple-system,system-ui,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-variant-ligatures:normal;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;margin-top:0px"></h2><div>The discussion of this proposal has really boiled down to how we roll this change out. I think it is important to understand why some of us have been pleading for us to follow agreed processes when making these changes, starting with this proposal, so I have written up some notes on why I think it is important to adopt a process for these kinds of changes and endeavour to stick to it.</div><div><br></div><div>We have a mechanism for getting everything the proposers want using established mechanisms. Why don't we follow them? If an urgent need had arisen to make this change then it would be easily understandable but this is proposal addressing a longstanding issue.</div><div><br></div><div>I get the sense that folks fear that there is a big push to freeze GHC/Haskell in its current configuration (or at least make it very difficult to change anything) to satisfy those that want to just make stuff with Haskell and stop all the experimentation and language development, and that this push needs to be stopped before it gathers any more momentum. I don't think this is all gamed out -- more a feeling or a vibe informing the debate.</div><div><br></div><div>I strongly believe this is a misunderstanding, and certainly where the proponents of these proposed protocols are concerned, nothing could be further from the truth. Properly understood, we want to create a framework that will remove a lot of friction in making changes, and also remove key stressors from all those maintaining the critical infrastructure outside of the core tools that make Haskell truly viable for real-world development.</div><div><br></div><div>I have written up my thoughts in <a href="https://gist.github.com/cdornan/68267aa63546e5d674cc8d083510c3e3" target="_blank">this gist</a>, explaining why I think we need the framework and why we should hold to it without good reason to do otherwise. Feel free to respond there or here as you see fit.</div><div><br></div><div>I remain opposed to this proposal in its current form, at least until I can understand why the changes have to be made outside of the framework for change we are trying to establish.</div><div><br></div><div>Chris</div><div> </div><div><br></div><div><br></div><div><div><blockquote type="cite"><div>On 5 Oct 2023, at 18:07, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:</div><br><div><div dir="auto"><div>Ah thanks, I forgot GHC2021 was the default (I'm personally stuck using pre-GHC2021 myself).<div dir="auto"><br></div><div dir="auto">In that case, I'm suggesting that we enable -Werror=severe in the next GHC20xx iteration, and leave GHC2021 etc. unaffected.</div><div dir="auto"><br></div><div dir="auto">Cheers</div><div dir="auto">Simon</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 5 Oct 2023, 07:56 Adam Gundry, <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.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">On 04/10/2023 22:04, Simon Marlow wrote:<br>
> My concrete suggestion is we EITHER<br>
> <br>
> * Enable -Werror=severe in future GHC20xx versions only, or<br>
> * Enable it by default and in future GHC20xx versions, but not in<br>
> GHC2021, Haskell2010, or Haskell98<br>
<br>
Sorry, I don't quite understand the difference between these options. <br>
What does it mean to enable -Werror=severe by default but not in <br>
GHC2021, given that GHC2021 is the (current) default?<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
> On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones <br>
> <<a href="mailto:simon.peytonjones@gmail.com" rel="noreferrer" target="_blank">simon.peytonjones@gmail.com</a> <mailto:<a href="mailto:simon.peytonjones@gmail.com" rel="noreferrer" target="_blank">simon.peytonjones@gmail.com</a>>> wrote:<br>
> <br>
> I must say that I am strongly influenced by the fact that<br>
> <br>
> * Matt Parsons<br>
> * Andrew Lelechenko (bodigrim)<br>
> <br>
> are both not just in favour, but *strongly *in favour. They must<br>
> think of the case as compelling, because they are both usually very<br>
> careful about unnecessary breakage.<br>
> <br>
> if we make -Werror=severe the default, then any new warning<br>
> added to -Wsevere is a new breaking change, and we would have to<br>
> judge it to be compelling enough by GR2<br>
> <br>
> <br>
> Yes indeed. But that's not a bug -- it's a feature.<br>
> <br>
> To be clear I have no strongly held opinion myself. Perhaps we<br>
> should canvas opinion among people using Haskell in production? We<br>
> did so with CLC but we could do so publicly.<br>
> <br>
> Simon<br>
> <br>
> On Wed, 4 Oct 2023 at 09:18, Simon Marlow <<a href="mailto:marlowsd@gmail.com" rel="noreferrer" target="_blank">marlowsd@gmail.com</a><br>
> <mailto:<a href="mailto:marlowsd@gmail.com" rel="noreferrer" target="_blank">marlowsd@gmail.com</a>>> wrote:<br>
> <br>
> I don't think this breaking change (namely making -Werror=severe<br>
> the default) meets the bar for "compelling reason" according to<br>
> GR2 of our proposed policy, so I'm voting against. It's<br>
> certainly not a bug or a security hole. Maybe you could argue<br>
> that it's a design flaw in the language, but I'm not all that<br>
> convinced. It's an unforced breaking change in my opinion. If we<br>
> add "makes it more difficult to shoot yourself in the foot" a<br>
> compelling enough reason to break GR1 then I think we've<br>
> weakened it significantly.<br>
> <br>
> Here's another problem: if we make -Werror=severe the default,<br>
> then any new warning added to -Wsevere is a new breaking change,<br>
> and we would have to judge it to be compelling enough by GR2. If<br>
> we don't make -Werror=severe the default, then we're not<br>
> restricted in what we can add to -Wsevere. Probably -Wsevere<br>
> would end up being more useful as a result.<br>
> <br>
> Cheers<br>
> Simon<br>
> <br>
> <br>
> On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones<br>
> <<a href="mailto:simon.peytonjones@gmail.com" rel="noreferrer" target="_blank">simon.peytonjones@gmail.com</a><br>
> <mailto:<a href="mailto:simon.peytonjones@gmail.com" rel="noreferrer" target="_blank">simon.peytonjones@gmail.com</a>>> wrote:<br>
> <br>
> Here's my summary:<br>
> <br>
> * There is strong (universal, even) support for the<br>
> `severe` category.<br>
> * There is pretty strong support for making severe<br>
> warnings into errors at some point. As Matt puts it<br>
> "this is not a question of GHC breaking things, but<br>
> rather /revealing/ and providing early-diagnosis for<br>
> /already broken/ things".<br>
> * But I think we are moving towards a policy of giving<br>
> users time to adapt via a deprecation cycle, whenever<br>
> that is feasible. And it is feasible here.<br>
> <br>
> So my suggestion would be:<br>
> <br>
> * When implemented, make `-Wwarn=severe` the default, but<br>
> add to each severe warning a deprecation-style message<br>
> saying that it'll become an error in the next iteration.<br>
> * In the next released, make `-Werror=severe` the default.<br>
> * Don't complicate matters by involving GHC2024. That is<br>
> another conversation, and even if we wanted to include<br>
> `-Werorr=severe` in GHC2024, we would *still* want a<br>
> deprecation cycle!<br>
> <br>
> Would that be acceptable?<br>
> <br>
> Simon<br>
> <br>
> On Fri, 29 Sept 2023 at 19:41, Adam Gundry<br>
> <<a href="mailto:adam@well-typed.com" rel="noreferrer" target="_blank">adam@well-typed.com</a> <mailto:<a href="mailto:adam@well-typed.com" rel="noreferrer" target="_blank">adam@well-typed.com</a>>> wrote:<br>
> <br>
> Dear Committee,<br>
> <br>
> It seems we are somewhat split on the -Wsevere proposal,<br>
> even assuming<br>
> it is introduced with a deprecation period (changing the<br>
> warning text<br>
> and adding the group in advance). There is consensus<br>
> that adding the<br>
> group by itself is fine, and potentially enabling<br>
> -Werror=severe under<br>
> GHC2024, but enabling it by default for existing code is<br>
> more controversial.<br>
> <br>
> Ultimately this is a judgement call about the value of<br>
> the proposal<br>
> versus the breakage it causes. I remain of the view that<br>
> it is<br>
> worthwhile. This is not merely about more aggressively<br>
> enforcing best<br>
> practice. Rather, it eliminates the risk of the following:<br>
> <br>
> * Suppose package A defines a type class, package B<br>
> depends on package<br>
> A, and package C depends on package B.<br>
> <br>
> * Now package A extends the type class definition with a<br>
> new method and<br>
> default methods. Everything still compiles; package B<br>
> now issues a<br>
> -Wmissing-methods warning (but is not actively<br>
> maintained, and the<br>
> author of package C is unlikely to look at warnings in<br>
> all their<br>
> dependencies).<br>
> <br>
> * Users of package C have to try to debug an infinite loop.<br>
> <br>
> Given that this change avoids a significant issue,<br>
> affected code has<br>
> been issuing warnings for many years, and impacted users<br>
> can very easily<br>
> set -Wwarn=severe either at the package level or the<br>
> project level, I<br>
> think is worth accepting the backwards compatibility<br>
> cost and the fact<br>
> that some Haskell2010 code will no longer be accepted by<br>
> default.<br>
> <br>
> Matt Parsons puts it well in the CLC thread, which is<br>
> pretty clearly in<br>
> favour of this proposal overall<br>
> (<a href="https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889</a> <<a href="https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889</a>>):<br>
> <br>
> > I think GHC should strive to make fewer breaking<br>
> changes, and make<br>
> those changes as easy-to-adopt as possible. But this is<br>
> not a question<br>
> of GHC breaking things, but rather revealing and providing<br>
> early-diagnosis for already broken things.<br>
> <br>
> Further opinions are welcome, of course.<br>
> <br>
> Adam<br>
> <br>
> <br>
> On 14/09/2023 09:32, Adam Gundry wrote:<br>
> > Dear Committee,<br>
> ><br>
> > Joachim, along with Oleg Grenrus, proposes to change<br>
> -Wmissing-methods<br>
> > and -Wmissing-fields warnings into errors by default<br>
> (retaining the<br>
> > option to downgrade them). I recommend we accept the<br>
> proposal.<br>
> ><br>
> > Proposal:<br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/571" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571</a><br>
> <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/571" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571</a>><br>
> > Rendered:<br>
> ><br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst</a> <<a href="https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst</a>><br>
> ><br>
> > This is primarily motivated by the fact that when<br>
> classes have default<br>
> > methods, missing methods can lead to runtime loops,<br>
> which are generally<br>
> > difficult to debug. Since in practice not all users<br>
> pay attention to<br>
> > warnings that do not inhibit compilation, it makes<br>
> sense to identify a<br>
> > class of warnings that are sufficiently serious to<br>
> require explicit<br>
> > action from the user to silence them.<br>
> ><br>
> > Since these warnings are currently not errors by<br>
> default, library<br>
> > authors experimentally assessing the impact of<br>
> changes may be lead to<br>
> > assume that introducing new methods/fields does not<br>
> lead to breakage<br>
> > (because downstream code will still compile). The<br>
> proposal thus makes it<br>
> > more obvious that adding a new method or field is a<br>
> breaking change.<br>
> ><br>
> > The proposal deliberately causes builds to fail by<br>
> default for some<br>
> > libraries that currently emit warnings. Oleg has<br>
> kindly performed impact<br>
> > assessments to identify such libraries, and the<br>
> breakage of a few<br>
> > packages seems worth the cost.<br>
> ><br>
> > It is easy to restore the warnings to their previous<br>
> classification by<br>
> > passing an option at build time, e.g. using<br>
> -Wno-error=missing-methods.<br>
> > Users can set such an option in cabal.project or<br>
> stack.yaml to work<br>
> > around breakage that is not promptly fixed by the<br>
> library author.<br>
> ><br>
> > This change does mean that GHC with -XHaskell98/2010<br>
> will by default<br>
> > reject some programs that are explicitly permitted by<br>
> the Haskell98/2010<br>
> > specification. I recommend we document this<br>
> infelicity, but accept it,<br>
> > as much of the benefit of the proposal is that it<br>
> applies by default.<br>
> ><br>
> > The proposal establishes the precedent that some<br>
> warnings may be treated<br>
> > as errors by default, and introduces a warning group<br>
> -Wsevere to<br>
> > classify them. This seems conceptually useful and<br>
> gives us the option to<br>
> > extend the -Wsevere set in the future (e.g. as a<br>
> final stage of<br>
> > deprecation before a feature is removed).<br>
> ><br>
> > Thoughts?<br>
> ><br>
> > Adam<br>
> ><br>
> ><br>
> > On 11/09/2023 20:25, Joachim Breitner wrote:<br>
> >> Dear Committee,<br>
> >><br>
> >> based on suggestions by Oleg Grenrus, I wrote a<br>
> proposal to introduce a<br>
> >> warning group -Wsevere for on-by-defaults,<br>
> error-by-default warnings,<br>
> >> and initially fill it with missing-methods and<br>
> missing-fields.<br>
> >><br>
> >><br>
> >><br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/571" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571</a><br>
> <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/571" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/571</a>><br>
> >><br>
> >><br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst</a> <<a href="https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst</a>><br>
> >><br>
> >> I’d like to nominate Adam as the shepherd, who<br>
> already reviewed it a<br>
> >> bit on Github.<br>
> >><br>
> >> Please guide us to a conclusion as outlined in<br>
> >><br>
> <a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process</a> <<a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process</a>><br>
> >><br>
> >><br>
> >> Cheers,<br>
> >> Joachim<br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
</blockquote></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></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>
</div></blockquote></div><br></div></div></div></div></blockquote></div>