<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">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">adam@well-typed.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">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>