[ghc-steering-committee] #571: -Wsevere, Shepherd: Adam (rec: accept)

Tue Sep 19 14:31:20 UTC 2023

On Tue, 19 Sept 2023 at 15:26, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I think that the motivation for this proposal is to make it harder to
> shoot yourself in the foot.
>
> Maybe implementing this "severe" *category*, but not changing its *default
> *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.
>

Absolutely! I'm only objecting to changing the default. Adding the "severe"
category by itself is useful, I agree.

Cheers
Simon

>
> Simon
>
> On Tue, 19 Sept 2023 at 14:35, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> 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.
>>
>> 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.
>>
>> For this reason I vote against this proposal.
>>
>> Chris
>>
>> On 19 Sep 2023, at 14:20, Simon Marlow <marlowsd at gmail.com> wrote:
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Cheers
>> Simon
>>
>>
>> On Tue, 19 Sept 2023 at 08:53, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> Just to clarify: I am not against change, or evolution.  I'm actually
>>> looking forward to progress. What I am against ist sudden breakage.
>>> As such, if there _is_ breakage (clc stackage is a subset), we have to
>>> assume there will be breakage in production codebases, most
>>> of which are likely not public.
>>>
>>> Can't we have `-Wcompat` enable `-Werror=missing-methods`, and
>>> `-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)
>>> 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
>>> is really `-Wcompat-error`, or we rather change the notion of -Wcompat
>>> to also promote warnings to errors early? In any case either the
>>> current documentation for -Wcompat would need to be adjusted, or we'd
>>> need something that signals new errors.
>>>
>>> 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,
>>> and that one can opt into this behaviour by enabling -Wcompat.
>>>
>>> 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
>>> 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
>>> 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
>>> 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
>>> branches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status already
>>> states anything but 9.4 and 9.6 won't see any further releases.
>>> Our current production compiler is 8.10, we could not switch to 9.2 due
>>> to performance regressions. And finally have almost everything
>>> compiling with 9.6, but are far from having any form of performance
>>> profile feedback on 9.6 yet.
>>>
>>> Again, I'm not against breakage per-se. I'm against sudden breakage.
>>> Managed evolution or however we want to call it, is something
>>> I'd absolutely support!
>>>
>>> Best,
>>>  Moritz
>>>
>>> On Tue, 19 Sept 2023 at 15:15, Adam Gundry <adam at well-typed.com> wrote:
>>>
>>>> On 18/09/2023 20:28, Richard Eisenberg wrote:
>>>> >
>>>> > Bottom line for me: I think we should implement and then experiment.
>>>> > Given the potentially delicate nature of this, I might even advocate
>>>> for
>>>> > implementing this in a release branch, so that as much of Hackage as
>>>> > possible actually has a hope of compiling. Then test to see where the
>>>> > breakage occurs. If were happy with the result, rebase the
>>>> > implementation on master. But I don't want us to get into a state
>>>> where
>>>> > we accept, implement, observe moderate breakage, and then blast ahead
>>>> > because the committee approved the idea.
>>>>
>>>> The breakage concern is worth thinking about, I agree, but fortunately
>>>> in this instance we don't need to wait for an implementation to run an
>>>> experiment. The change can be relatively effectively simulated by
>>>> compiling with -Werror=missing-methods -Werror=missing-fields, and
>>>> indeed Oleg has done so already for clc-stackage as he reports here:
>>>>
>>>>
>>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536
>>>>
>>>>
>>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737
>>>>
>>>> Out of nearly 3000 packages, he found 22 were broken by
>>>> -Werror=missing-methods and 9 by -Werror=missing-fields.
>>>>
>>>> Adam
>>>>
>>>>
>>>> --
>>>> Adam Gundry, Haskell Consultant
>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>
>>>> Registered in England & Wales, OC335890
>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230919/15f18f0b/attachment-0001.html>