[ghc-steering-committee] #571: -Wsevere, Shepherd: Adam (rec: accept)
Chris Dornan
chris at chrisdornan.com
Sun Oct 8 18:11:34 UTC 2023
The discussion of this proposal has really boiled down to how we roll this change out. I think it is important to understand why some of us have been pleading for us to follow agreed processes when making these changes, starting with this proposal, so I have written up some notes on why I think it is important to adopt a process for these kinds of changes and endeavour to stick to it.
We have a mechanism for getting everything the proposers want using established mechanisms. Why don't we follow them? If an urgent need had arisen to make this change then it would be easily understandable but this is proposal addressing a longstanding issue.
I get the sense that folks fear that there is a big push to freeze GHC/Haskell in its current configuration (or at least make it very difficult to change anything) to satisfy those that want to just make stuff with Haskell and stop all the experimentation and language development, and that this push needs to be stopped before it gathers any more momentum. I don't think this is all gamed out -- more a feeling or a vibe informing the debate.
I strongly believe this is a misunderstanding, and certainly where the proponents of these proposed protocols are concerned, nothing could be further from the truth. Properly understood, we want to create a framework that will remove a lot of friction in making changes, and also remove key stressors from all those maintaining the critical infrastructure outside of the core tools that make Haskell truly viable for real-world development.
I have written up my thoughts in this gist <https://gist.github.com/cdornan/68267aa63546e5d674cc8d083510c3e3>, explaining why I think we need the framework and why we should hold to it without good reason to do otherwise. Feel free to respond there or here as you see fit.
I remain opposed to this proposal in its current form, at least until I can understand why the changes have to be made outside of the framework for change we are trying to establish.
Chris
> On 5 Oct 2023, at 18:07, Simon Marlow <marlowsd at gmail.com> wrote:
>
> Ah thanks, I forgot GHC2021 was the default (I'm personally stuck using pre-GHC2021 myself).
>
> In that case, I'm suggesting that we enable -Werror=severe in the next GHC20xx iteration, and leave GHC2021 etc. unaffected.
>
> Cheers
> Simon
>
>
> On Thu, 5 Oct 2023, 07:56 Adam Gundry, <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>> On 04/10/2023 22:04, Simon Marlow wrote:
>> > My concrete suggestion is we EITHER
>> >
>> > * Enable -Werror=severe in future GHC20xx versions only, or
>> > * Enable it by default and in future GHC20xx versions, but not in
>> > GHC2021, Haskell2010, or Haskell98
>>
>> Sorry, I don't quite understand the difference between these options.
>> What does it mean to enable -Werror=severe by default but not in
>> GHC2021, given that GHC2021 is the (current) default?
>>
>> Cheers,
>>
>> Adam
>>
>>
>> > On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones
>> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com> <mailto:simon.peytonjones at gmail.com <mailto: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 <mailto:marlowsd at gmail.com>
>> > <mailto:marlowsd at gmail.com <mailto: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 <mailto:simon.peytonjones at gmail.com>
>> > <mailto:simon.peytonjones at gmail.com <mailto: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 <mailto:adam at well-typed.com> <mailto:adam at well-typed.com <mailto: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 <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
>> > <https://github.com/ghc-proposals/ghc-proposals/pull/571>
>> > > Rendered:
>> > >
>> > https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <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/pull/571>
>> > >>
>> > >>
>> > https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231008/d7601033/attachment-0001.html>
More information about the ghc-steering-committee
mailing list