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

Wed Oct 4 08:52:56 UTC 2023

>
> isn't that effectively canvasing a wider opinion among people
> using Haskell in production?
>

Not really?  We would not get any feedback, would we?  Or perhaps we might
hear from a couple of folk who don't like the change, but we'd hear nothing
from a (I'm guessing) silent majority who thought "great".

S

On Wed, 4 Oct 2023 at 09:38, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Let me pose a slightly loaded question on this:
>
> if we had -Werror=severe by default, and severe being empty, as well as
> adding notes to warnings we intent to promote to
> severe (This warning will be part of severe in GHC X.Y.Z and therefore
> become an error. See https://...), isn't that effectively
> canvasing a wider opinion among people using Haskell in production?
>
> Cheers,
>  Moritz
>
> On Wed, 4 Oct 2023 at 16:28, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I must say that I am strongly influenced by the fact that
>>
>>    - Matt Parsons
>>    - Andrew Lelechenko (bodigrim)
>>
>> are both not just in favour, but *strongly *in favour.  They must think
>> of the case as compelling, because they are both usually very careful about
>> unnecessary breakage.
>>
>> if we make -Werror=severe the default, then any new warning added to
>>> -Wsevere is a new breaking change, and we would have to judge it to be
>>> compelling enough by GR2
>>>
>>
>> Yes indeed.  But that's not a bug -- it's a feature.
>>
>> To be clear I have no strongly held opinion myself.   Perhaps we should
>> canvas opinion among people using Haskell in production? We did so with CLC
>> but we could do so publicly.
>>
>> Simon
>>
>> On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com> wrote:
>>
>>> I don't think this breaking change (namely making -Werror=severe the
>>> default) meets the bar for "compelling reason" according to GR2 of our
>>> proposed policy, so I'm voting against. It's certainly not a bug or a
>>> security hole. Maybe you could argue that it's a design flaw in the
>>> language, but I'm not all that convinced. It's an unforced breaking change
>>> in my opinion. If we add "makes it more difficult to shoot yourself in the
>>> foot" a compelling enough reason to break GR1 then I think we've weakened
>>> it significantly.
>>>
>>> Here's another problem: if we make -Werror=severe the default, then any
>>> new warning added to -Wsevere is a new breaking change, and we would have
>>> to judge it to be compelling enough by GR2. If we don't make -Werror=severe
>>> the default, then we're not restricted in what we can add to -Wsevere.
>>> Probably -Wsevere would end up being more useful as a result.
>>>
>>> Cheers
>>> Simon
>>>
>>>
>>> On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> Here's my summary:
>>>>
>>>>    - There is strong (universal, even) support for the `severe`
>>>>    category.
>>>>    - There is pretty strong support for making severe warnings into
>>>>    errors at some point.  As Matt puts it "this is not a question of GHC
>>>>    breaking things, but rather *revealing* and providing
>>>>    early-diagnosis for *already broken* things".
>>>>    - But I think we are moving towards a policy of giving users time
>>>>    to adapt via a deprecation cycle, whenever that is feasible.  And it is
>>>>    feasible here.
>>>>
>>>> So my suggestion would be:
>>>>
>>>>    - When implemented, make `-Wwarn=severe` the default, but add to
>>>>    each severe warning a deprecation-style message saying that it'll become an
>>>>    error in the next iteration.
>>>>    - In the next released, make `-Werror=severe` the default.
>>>>    - Don't complicate matters by involving GHC2024.  That is another
>>>>    conversation, and even if we wanted to include `-Werorr=severe` in GHC2024,
>>>>    we would *still* want a deprecation cycle!
>>>>
>>>> Would that be acceptable?
>>>>
>>>> Simon
>>>>
>>>> On Fri, 29 Sept 2023 at 19:41, Adam Gundry <adam at well-typed.com> wrote:
>>>>
>>>>> Dear Committee,
>>>>>
>>>>> It seems we are somewhat split on the -Wsevere proposal, even assuming
>>>>> it is introduced with a deprecation period (changing the warning text
>>>>> and adding the group in advance). There is consensus that adding the
>>>>> group by itself is fine, and potentially enabling -Werror=severe under
>>>>> GHC2024, but enabling it by default for existing code is more
>>>>> controversial.
>>>>>
>>>>> Ultimately this is a judgement call about the value of the proposal
>>>>> versus the breakage it causes. I remain of the view that it is
>>>>> worthwhile. This is not merely about more aggressively enforcing best
>>>>> practice. Rather, it eliminates the risk of the following:
>>>>>
>>>>> * Suppose package A defines a type class, package B depends on package
>>>>> A, and package C depends on package B.
>>>>>
>>>>> * Now package A extends the type class definition with a new method
>>>>> and
>>>>> default methods. Everything still compiles; package B now issues a
>>>>> -Wmissing-methods warning (but is not actively maintained, and the
>>>>> author of package C is unlikely to look at warnings in all their
>>>>> dependencies).
>>>>>
>>>>> * Users of package C have to try to debug an infinite loop.
>>>>>
>>>>> Given that this change avoids a significant issue, affected code has
>>>>> been issuing warnings for many years, and impacted users can very
>>>>> easily
>>>>> set -Wwarn=severe either at the package level or the project level, I
>>>>> think is worth accepting the backwards compatibility cost and the fact
>>>>> that some Haskell2010 code will no longer be accepted by default.
>>>>>
>>>>> Matt Parsons puts it well in the CLC thread, which is pretty clearly
>>>>> in
>>>>> favour of this proposal overall
>>>>> (
>>>>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>>>>> ):
>>>>>
>>>>>  > I think GHC should strive to make fewer breaking changes, and make
>>>>> those changes as easy-to-adopt as possible. But this is not a question
>>>>> of GHC breaking things, but rather revealing and providing
>>>>> early-diagnosis for already broken things.
>>>>>
>>>>> Further opinions are welcome, of course.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On 14/09/2023 09:32, Adam Gundry wrote:
>>>>> > Dear Committee,
>>>>> >
>>>>> > Joachim, along with Oleg Grenrus, proposes to change
>>>>> -Wmissing-methods
>>>>> > and -Wmissing-fields warnings into errors by default (retaining the
>>>>> > option to downgrade them). I recommend we accept the proposal.
>>>>> >
>>>>> > Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>>> > Rendered:
>>>>> >
>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>>> >
>>>>> > This is primarily motivated by the fact that when classes have
>>>>> default
>>>>> > methods, missing methods can lead to runtime loops, which are
>>>>> generally
>>>>> > difficult to debug. Since in practice not all users pay attention to
>>>>> > warnings that do not inhibit compilation, it makes sense to identify
>>>>> a
>>>>> > class of warnings that are sufficiently serious to require explicit
>>>>> > action from the user to silence them.
>>>>> >
>>>>> > Since these warnings are currently not errors by default, library
>>>>> > authors experimentally assessing the impact of changes may be lead
>>>>> to
>>>>> > assume that introducing new methods/fields does not lead to breakage
>>>>> > (because downstream code will still compile). The proposal thus
>>>>> makes it
>>>>> > more obvious that adding a new method or field is a breaking change.
>>>>> >
>>>>> > The proposal deliberately causes builds to fail by default for some
>>>>> > libraries that currently emit warnings. Oleg has kindly performed
>>>>> impact
>>>>> > assessments to identify such libraries, and the breakage of a few
>>>>> > packages seems worth the cost.
>>>>> >
>>>>> > It is easy to restore the warnings to their previous classification
>>>>> by
>>>>> > passing an option at build time, e.g. using
>>>>> -Wno-error=missing-methods.
>>>>> > Users can set such an option in cabal.project or stack.yaml to work
>>>>> > around breakage that is not promptly fixed by the library author.
>>>>> >
>>>>> > This change does mean that GHC with -XHaskell98/2010 will by default
>>>>> > reject some programs that are explicitly permitted by the
>>>>> Haskell98/2010
>>>>> > specification. I recommend we document this infelicity, but accept
>>>>> it,
>>>>> > as much of the benefit of the proposal is that it applies by default.
>>>>> >
>>>>> > The proposal establishes the precedent that some warnings may be
>>>>> treated
>>>>> > as errors by default, and introduces a warning group -Wsevere to
>>>>> > classify them. This seems conceptually useful and gives us the
>>>>> option to
>>>>> > extend the -Wsevere set in the future (e.g. as a final stage of
>>>>> > deprecation before a feature is removed).
>>>>> >
>>>>> > Thoughts?
>>>>> >
>>>>> > Adam
>>>>> >
>>>>> >
>>>>> > On 11/09/2023 20:25, Joachim Breitner wrote:
>>>>> >> Dear Committee,
>>>>> >>
>>>>> >> based on suggestions by Oleg Grenrus, I wrote a proposal to
>>>>> introduce a
>>>>> >> warning group -Wsevere for on-by-defaults, error-by-default
>>>>> warnings,
>>>>> >> and initially fill it with missing-methods and missing-fields.
>>>>> >>
>>>>> >>
>>>>> >> https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>>> >>
>>>>> >>
>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>>> >>
>>>>> >> I’d like to nominate Adam as the shepherd, who already reviewed it a
>>>>> >> bit on Github.
>>>>> >>
>>>>> >> Please guide us to a conclusion as outlined in
>>>>> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>> >>
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Joachim
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231004/89dc2fe9/attachment-0001.html>