[ghc-steering-committee] #571: -Wsevere, Shepherd: Adam (rec: accept)
Simon Peyton Jones
simon.peytonjones at gmail.com
Mon Oct 9 09:18:14 UTC 2023
OK so concretely you are saying
- Expressing support for the general rules in the draft GHC stability
policy
<https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>
.
- Advocating for a deprecation cycle for this specific -Wsevere
proposal, rather than introducing it immediately.
OK now I understand.
Moreover, you add
My favoured solution is to predicate this new behaviour on a language
> extension and incorporate that into GHC2024
>
I'm not quite sure what you mean here. I think that you could be saying:
- Do not add -Wsevere
- Instead add an extension -XMissingMethods, on by default.
- At some point, after a deprecation cycle, make -XNoMissingMethods
become the default.
- -Wwarn=missing-methods would be unaffected; but would become redundant
with -XNoMissingMethods.
and follow the same pattern for missing-fields.
That is, you want to address
https://github.com/ghc-proposals/ghc-proposals/issues/615 by doubling down
on language extensions, rather than by bigging-up warning flags.
Do I have that correct? Perhaps you can make the case on that discussion
thread?
Simon
On Mon, 9 Oct 2023 at 09:45, Chris Dornan <chris at chrisdornan.com> wrote:
> When I refer to `the framework` I was thinking of the *GHC Stability
> Policy* document that you created (where we try not to introduce breaking
> changes, but when we do we use deprecation cycles unless there is a good
> reason not to).
>
> My favoured solution is to predicate this new behaviour on a language
> extension and incorporate that into GHC2024 -- that could be done using
> established mechanisms -- but my overriding concern is that the changes in
> behaviour be fitted into the framework for introducing breaking changes
> that we have been discussing these past few weeks in the *GHC Stability
> Policy* document.
>
> The key to me is that it be fitted into an agreed policy for making
> breaking changes, not that it adhere to my particular preferences, or the
> state of a particular proposal under discussion -- hence my somewhat
> abstract choice of terms.
>
> Is that clear? I don't want to prescribe here (though I have preferences)
> but please give me something that could plausibly be part of a general
> policy for introducing breaking changes moving forward.
>
> Chris
>
> On 9 Oct 2023, at 09:09, Simon Peyton Jones <simon.peytonjones at gmail.com>
> wrote:
>
> 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, can you just lay out "the framework for change we are trying to
> establish"? I accept the importance of the considerations you describe, in
> this email and in your gist. So I understand what you are arguing
> *against*; but I don't yet see what you are arguing *for*.
>
> It's hard to argue against "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". But what, precisely, do you
> have in mind?
>
> And in the context of this specific proposal, what are you arguing for?
>
> Thanks. Sorry to be dim.
>
> Simon
>
>
> On Sun, 8 Oct 2023 at 19:12, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> 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> 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>>
>>> 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>> 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>> 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>> 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
>>
>>
>> _______________________________________________
>> 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/20231009/ec59c3fb/attachment-0001.html>
More information about the ghc-steering-committee
mailing list