<div dir="ltr"><div dir="ltr">On Tue, 19 Sept 2023 at 15:26, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</a>> wrote:</div><div class="gmail_quote"><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 style="font-family:tahoma,sans-serif">I think that the motivation for this proposal is to make it harder to shoot yourself in the foot.</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Maybe implementing this "severe" <b>category</b>, but not changing its <b>default </b>to error, would get us some of the way there?  Then "best-practice guidance" could be "use -Werror=severe", and job done.  That's a bit easier to say than saying "use -Werrror=missing-methods -Werror= ..." etc.</div></div></blockquote><div><br></div><div>Absolutely! I'm only objecting to changing the default. Adding the "severe" category by itself is useful, I agree.<br></div><div><br></div><div>Cheers</div><div>Simon<br></div><div> </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 style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Sept 2023 at 14:35, 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>Like Simon M I habitually develop with -Wall -Werror, and like Moritz I think we really need to be very careful about deliberately breaking packages.<div><br></div><div>For sure, if we were starting anew I would be be sympathetic to treating them as errors, but, for me, that isn't a good enough reason to make this breaking change.</div><div><br></div><div>For this reason I vote against this proposal. </div><div><br></div><div>Chris<br><div><br><blockquote type="cite"><div>On 19 Sep 2023, at 14:20, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>For those not aware, Hackage right now rejects packages with `-Wall -Werror` in their ghc-options because warnings change between GHC versions so this tends to lead to unnecessary breakage. I think that's a good policy, even though I use `-Wall -Werror` everywhere when developing.</div><div><br></div><div>Interestingly, this proposal creates exactly the same kind of risk, by making some existing warnings errors by default and introducing the possibility that the set of warnings treated this way might change in the future. Admittedly it's a smaller risk than `-Wall -Werror`, but it's still a risk for developers.<br></div><div><br></div><div>Also note that `ghc -XHaskell2010` will reject some legal Haskell2010 programs, unless you also say `-Wwarn=severe`. We are normally careful to document the ways in which GHC deviates from the language definition in the user guide.<br></div><div><br></div><div>I can see the motivation, but I have to vote against here. I don't think we should change the set of programs accepted by the compiler unless absolutely necessary. If it's legal code today, it should be accepted by future versions of the compiler unless we have a really good reason to change that.<br></div><div><br></div><div>Cheers</div><div>Simon<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Sept 2023 at 08:53, 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:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Just to clarify: I am not against change, or evolution.  I'm actually looking forward to progress. What I am against ist sudden breakage.<div>As such, if there _is_ breakage (clc stackage is a subset), we have to assume there will be breakage in production codebases, most</div><div>of which are likely not public.</div><div><br></div><div>Can't we have `-Wcompat` enable `-Werror=missing-methods`, and `-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)</div><div>Advertise this prominently in the release notes for GHC 9.10? And then enable this fully in GHC 9.14? Though I guess the flag we want</div><div>is really `-Wcompat-error`, or we rather change the notion of -Wcompat to also promote warnings to errors early? In any case either the</div><div>current documentation for -Wcompat would need to be adjusted, or we'd need something that signals new errors.</div><div><br></div><div>Ideally I'd like to see something like a warning for `missing-methods`, with an additional note that this will become an error in GHC X.Y,</div><div>and that one can opt into this behaviour by enabling -Wcompat.</div><div><br></div><div>My test for support is generally: can I take existing code unmodified, swap out the compiler, and it will still compile? That way I can report</div><div>back regressions, bugs, ... early on during alphas, betas, and release candidates. Right now I can't. I usually have to wait for x.y.4+. That</div><div>also means the feedback for anyone working on GHC is terrible. You won't hear about bugs until late in the release cycle where the</div><div>master branch has moved forward by a lot. At the same time it's painful for integrators who end up having to backport and patch old</div><div>branches. <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status</a> already states anything but 9.4 and 9.6 won't see any further releases.</div><div>Our current production compiler is 8.10, we could not switch to 9.2 due to performance regressions. And finally have almost everything</div><div>compiling with 9.6, but are far from having any form of performance profile feedback on 9.6 yet.</div><div><br></div><div>Again, I'm not against breakage per-se. I'm against sudden breakage. Managed evolution or however we want to call it, is something</div><div>I'd absolutely support!</div><div><br></div><div>Best,</div><div> Moritz</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Sept 2023 at 15:15, 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 18/09/2023 20:28, Richard Eisenberg wrote:<br>
><br>
> Bottom line for me: I think we should implement and then experiment. <br>
> Given the potentially delicate nature of this, I might even advocate for <br>
> implementing this in a release branch, so that as much of Hackage as <br>
> possible actually has a hope of compiling. Then test to see where the <br>
> breakage occurs. If were happy with the result, rebase the <br>
> implementation on master. But I don't want us to get into a state where <br>
> we accept, implement, observe moderate breakage, and then blast ahead <br>
> because the committee approved the idea.<br>
<br>
The breakage concern is worth thinking about, I agree, but fortunately <br>
in this instance we don't need to wait for an implementation to run an <br>
experiment. The change can be relatively effectively simulated by <br>
compiling with -Werror=missing-methods -Werror=missing-fields, and <br>
indeed Oleg has done so already for clc-stackage as he reports here:<br>
<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536</a><br>
<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737</a><br>
<br>
Out of nearly 3000 packages, he found 22 were broken by <br>
-Werror=missing-methods and 9 by -Werror=missing-fields.<br>
<br>
Adam<br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="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>
_______________________________________________<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>
_______________________________________________<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>
_______________________________________________<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>_______________________________________________<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>