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

Wed Oct 4 09:28:25 UTC 2023

I guess we'll always have to deal with some form of selection bias? If we
put it into the warning, I agree that the selection will mostly
be people who run into it and are opposed to it. If we put it onto
discourse we'll end up with people who frequent discourse, but that
does need to correlate with people working with haskell. If we put it onto
reddit or the cafe or elsewhere we always end up with that
selection bias. I could ask at $work, but that would also mean I get
selection bias only from those at $work, and I'm not certain it's
a representative sample of people working with haskell?

We could put it into a warning, pointing to a github issue (so people can
provide feedback), and concurrently publish this with the
release notes? Would explicitly asking "please provide your feedback" in
the warning motivate the potential silent majority? Without
hard numbers it would even be hard to judge how large the (and if) those
that find their way to the issue then would even constitute
a minority?

Would 10, 50, 100 people raising concerns mean anything? How many people
working with haskell are there?

I'm happy to run a poll at $work, and report the results back. Something
along the lines of:

> Regarding ghc-proposals#571, which introduces a new warning category:
> severe

- Would you prefer this to be -Werror=severe by default? Thus turning
> existing warnings into hard errors with a breaking change?

- Have a grace period where the warnings that will turn into errors clearly
> state this in their warning? Thus giving a grace period into -Werror=severe
> by default.

- We should not have warnings be errors by default that's what the -Werror
> opt-in is for? There should be no -Werror=severe ever.

?

On Wed, 4 Oct 2023 at 16:53, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> 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/8ccb4eb4/attachment-0001.html>