<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">I'd love to know your views about the proposed "General Rules" described here: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305">https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305</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 knew our stance on these, it might help with our debate about the particular proposal #571.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Sept 2023 at 14:13, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com">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="auto">Thank you Simon! </div><div dir="auto"><br></div><div dir="auto">I think this raises a good point, in that _any_ breaking change should stand well on its own wrt to a cost/benefit analysis.</div><div dir="auto"><br></div><div dir="auto">I’m not sure if we disagree or not.  I’ve assumed that the majority wants to make these changes.  I also often do not feel sufficiently capable enough to make a convincing argument against a specific change. </div><div dir="auto"><br></div><div dir="auto">Thus under the assumption that we are going to make a breaking change (because the majority want this), I feel very strongly about informing end users beforehand as well as the quality control aspect of being able to run regression tests by just swapping out the compiler trivially.</div><div dir="auto"><br></div><div dir="auto">Thus *if* we are making a breaking change, I do not believe that a migration phase reduces the costs much (you still need to adjust your code), but I consider a breaking change without migration phase to be significantly worse to a breaking change with migration phase.</div><div dir="auto"><br></div><div dir="auto">The difference for me practically lies in the following:</div><div dir="auto">If we migrate to a new compiler, a team of engineers start doing the initial migration for us (this means adding the new compiler to CI, and making sure existing code at least builds), this happens for multiple projects/components in dependency order.</div><div dir="auto"><br></div><div dir="auto">After this has happened the project/component teams use the new compiler and fix their code.</div><div dir="auto"><br></div><div dir="auto">If we have migration warnings for upcoming breaking changes, the work shifts from the new-compiler-across-multiple-projects team into the project teams.</div><div dir="auto"><br></div><div dir="auto">This makes the whole add new compiler process significantly faster, and means less friction. It also means the project teams who have much better knowledge of their specific project can address the warnings better than the migration team which has to dig deep into existing code bases, get familiar with the code to make the necessity adjustments (or request pair sessions that take time from other tasks).</div><div dir="auto"><br></div><div dir="auto">It also gives one more opportunity for the community to raise their hand and say, oh hell no, that’s a stupid idea; I’m going to complain about this! (I’ve been told this more than once; migration phases could also be seen as community inquiery, to get feedback from actual practitioners).</div><div dir="auto"><br></div><div dir="auto">After writing this all down, I guess my push for “if breaking change, then only with migration phase” is orthogonal to “should we have breaking changes to begin with?”</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">  Moritz</div><div dir="auto"><br></div><div dir="auto">On Thu, 21 Sep 2023 at 8:35 PM, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:<br></div><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>I might be an outlier here, but deferring the change to a later release and adding an intermediate warning doesn't make it any less bad.<br></div><div><br></div><div dir="auto">This is one cultural aspect of our community I'd like to shift: the expectation that it's OK to make breaking changes as long as you warn about them or go through a migration cycle. It just isn't! (and I speak as someone who used to make lots of changes, I'm now fully repentant!). That's not to say that we shouldn't ever change anything, but when considering the cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it just defers it.<br></div><div><br></div><div>Cheers</div></div><div dir="ltr"><div>Simon<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 Sept 2023 at 08:25, 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">I agree with Joachim's position here.<br>
<br>
Having a -Wsevere group at all would be a good start, but the problem <br>
with stopping at "best-practice guidance" rather than changing the <br>
defaults is that it benefits only those who learn about and follow the <br>
guidance. So it remains a footgun for newcomers.<br>
<br>
Regarding migration, given that GHC has issued these warnings by default <br>
for some time, I don't think we need be too shy about upgrading their <br>
severity. We could have -Wcompat imply -Werror=severe, but that <br>
complicates the semantics of warning groups, and will help only those <br>
who use -Wcompat but don't fix warnings that occur with -Wdefault.<br>
<br>
I suppose as Moritz suggests we could introduce and advertise -Wsevere <br>
in 9.10, and mention in the warning message that this will be an error <br>
in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so <br>
9.10 would give something like:<br>
<br>
M.hs:8:10: warning: [-Wmissing-methods]<br>
     • No explicit implementation for<br>
         ‘<>’<br>
     • In the instance declaration for ‘Semigroup T’<br>
     • Warning: this may lead to an infinite loop or runtime exception.<br>
     • This will become an error by default in a future GHC release;<br>
       use -Werror=severe to make severe warnings into errors now.<br>
<br>
Then in a future release:<br>
<br>
M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]<br>
     • No explicit implementation for<br>
         ‘<>’<br>
     • In the instance declaration for ‘Semigroup T’<br>
     • Warning: this may lead to an infinite loop or runtime exception.<br>
     • Use -Wwarn=missing-methods to permit this anyway.<br>
<br>
Would that be a reasonable compromise?<br>
<br>
Adam<br>
<br>
<br>
On 19/09/2023 22:13, Joachim Breitner wrote:<br>
> Hi,<br>
> <br>
> Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:<br>
>> Maybe implementing this "severe" category, but not changing its<br>
>> default to error, would get us some of the way there?  Then "best-<br>
>> practice guidance" could be "use -Werror=severe", and job done.<br>
>> That's a bit easier to say than saying "use -Werrror=missing-methods<br>
>> -Werror= ..." etc.<br>
> <br>
> anyone using `-Werror` would already get this behavior. So what is the<br>
> useful for using `-Werror=severe` instead? Presumably the rationale is:<br>
> <br>
>   -Werror, while great _during_ development or in leaf packages, is not<br>
>   is not good idea in _released_ code, i.e. code that is compiled by<br>
>   others, as that code needs to keep working even as compilers and<br>
>   dependencies change, such as libraries on hackage, or executables<br>
>   built by distro packagers.<br>
>   That’s why -Werror is frowned upon there.<br>
> <br>
>   But some changes in upstream packages _ought_ to cause compilation to<br>
>   fail, because they really need downstream code changes. These will<br>
>   cause severe warnings, and therefore -Werror=severe is desirable<br>
>   even for released code.<br>
> <br>
> Is that a good way of phrasing your thoughts there?<br>
> <br>
> It looks reasonable to me; if we think of deferable type error as<br>
> severe warnings, it totally fits this description: It would be<br>
> _possible_ to keep compiling the downstream code, but it would not be<br>
> desirable. That's why compilation fails, and that’s why we don’t defer<br>
> type errors by default.<br>
> <br>
> But if -Werror=severe is desirable generally, it would be unfortunate<br>
> if we cannot make it the default. If not right away, then maybe with a<br>
> suitable migration strategy? (Although I wonder if there are many users<br>
> out there that pay attention to deprecation warnings, e.g. watch<br>
> -Wdeprecation, that would not have already fixed -Wdefault warnings<br>
> about missing fields/methods already…)<br>
> <br>
> <br>
> Cheers,<br>
> Joachim<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></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>