(I'd argue that most errors can be turned into warnings via -fdefer-type-errors. It's really coarse though.) When reading the summary, I was anticipating voting against the proposal, turning warnings into errors by default creates spurious work for package maintainers. But I think I'm now convinced. Joachim & Oleg's point is that we want to consider creating additional `-Wsevere` warnings *to not be backward compatible*. It's an obligation on GHC designers, and on package maintainers: such change must be considered very carefully and must be properly documented. If we break compatibility this way, we want to trigger as many errors as possible, so that packages get fixed (which they almost certainly need to). This is the criterion for having a warning be part of `-Wsevere`. And the two first contestants (missing methods and missing fields) absolutely seem to fit the bill. So I'm in favour. I have no opinion about whether there is a better way to describe the spectrum of error-to-warning, as per Simon's musing. I agree that the CLC should be consulted on this, as it also imposes duties on them. /Arnaud On Thu, 14 Sept 2023 at 11:10, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

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'm fine with making these errors, provided the impact on library authors is not too severe. But this is a breaking change and people will shout at us.

*Moritz*, on the face of it this is just the kind of thing you dislike -- and yet it makes it much harder to inadvertently create truly nasty bugs.

This doesn't affect the API of base, and so is no in CLC purview, but I'd quite like to ask their opinion. What I don't want is for us to accept it, and then have a firestorm of complaints. I think the case is strong: debugging infinite loops is very painful.

The proposal establishes the precedent that some warnings may be treated

...

as errors by default

This is a funny thing. A warning that is an error by default is perhaps.. an error? Or to put it another way, perhaps all errors are just warnings that are treated as errors by default?

Perhaps this new beast is an error that can be turned into a warning? (Most errors cannot.)

I'm not arguing against the proposal, just wondering if there is a simpler way to say this.

Simon

On Thu, 14 Sept 2023 at 09:33, 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-s...

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-s...

...

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

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-12799... 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

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 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 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-12799...

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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. Simon On Tue, 19 Sept 2023 at 14:35, Chris Dornan 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 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@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 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-12799...

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

My opposition is entirely grounded in the change of default behaviour; otherwise i am in favour. On Tue, 19 Sep 2023 at 15:31, Simon Marlow wrote:

On Tue, 19 Sept 2023 at 15:26, Simon Peyton Jones < simon.peytonjones@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 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 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@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 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

...

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

for 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-12799...

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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

See discussion on the CLC issue https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-... Some are positively keen on making severe warnings into errors by default, just the opposite of our current discussion! Simon On Tue, 19 Sept 2023 at 17:21, Arnaud Spiwack wrote:

Is the general consensus on this thread that defaults should never change, even if better defaults are discovered?

On Tue, 19 Sept 2023 at 17:13, Chris Dornan wrote:

...

My opposition is entirely grounded in the change of default behaviour; otherwise i am in favour.

On Tue, 19 Sep 2023 at 15:31, Simon Marlow wrote:

...

On Tue, 19 Sept 2023 at 15:26, Simon Peyton Jones < simon.peytonjones@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 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 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@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 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-12799... > > 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@haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I agree with Joachim's position here. Having a -Wsevere group at all would be a good start, but the problem with stopping at "best-practice guidance" rather than changing the defaults is that it benefits only those who learn about and follow the guidance. So it remains a footgun for newcomers. Regarding migration, given that GHC has issued these warnings by default for some time, I don't think we need be too shy about upgrading their severity. We could have -Wcompat imply -Werror=severe, but that complicates the semantics of warning groups, and will help only those who use -Wcompat but don't fix warnings that occur with -Wdefault. I suppose as Moritz suggests we could introduce and advertise -Wsevere in 9.10, and mention in the warning message that this will be an error in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so 9.10 would give something like: M.hs:8:10: warning: [-Wmissing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • This will become an error by default in a future GHC release; use -Werror=severe to make severe warnings into errors now. Then in a future release: M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • Use -Wwarn=missing-methods to permit this anyway. Would that be a reasonable compromise? Adam On 19/09/2023 22:13, Joachim Breitner wrote:

Hi,

Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:

...

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.

anyone using `-Werror` would already get this behavior. So what is the useful for using `-Werror=severe` instead? Presumably the rationale is:

-Werror, while great _during_ development or in leaf packages, is not is not good idea in _released_ code, i.e. code that is compiled by others, as that code needs to keep working even as compilers and dependencies change, such as libraries on hackage, or executables built by distro packagers. That’s why -Werror is frowned upon there.

But some changes in upstream packages _ought_ to cause compilation to fail, because they really need downstream code changes. These will cause severe warnings, and therefore -Werror=severe is desirable even for released code.

Is that a good way of phrasing your thoughts there?

It looks reasonable to me; if we think of deferable type error as severe warnings, it totally fits this description: It would be _possible_ to keep compiling the downstream code, but it would not be desirable. That's why compilation fails, and that’s why we don’t defer type errors by default.

But if -Werror=severe is desirable generally, it would be unfortunate if we cannot make it the default. If not right away, then maybe with a suitable migration strategy? (Although I wonder if there are many users out there that pay attention to deprecation warnings, e.g. watch -Wdeprecation, that would not have already fixed -Wdefault warnings about missing fields/methods already…)

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

yes. That would be great and resolve my reservations!

Great. I think the CLC would actively support this too, if I read their comments correctly. Simon On Wed, 20 Sept 2023 at 08:30, Moritz Angermann wrote:

Adam,

yes. That would be great and resolve my reservations!

Cheers, Moritz

On Wed, 20 Sept 2023 at 15:25, Adam Gundry wrote:

...

I agree with Joachim's position here.

Having a -Wsevere group at all would be a good start, but the problem with stopping at "best-practice guidance" rather than changing the defaults is that it benefits only those who learn about and follow the guidance. So it remains a footgun for newcomers.

Regarding migration, given that GHC has issued these warnings by default for some time, I don't think we need be too shy about upgrading their severity. We could have -Wcompat imply -Werror=severe, but that complicates the semantics of warning groups, and will help only those who use -Wcompat but don't fix warnings that occur with -Wdefault.

I suppose as Moritz suggests we could introduce and advertise -Wsevere in 9.10, and mention in the warning message that this will be an error in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so 9.10 would give something like:

M.hs:8:10: warning: [-Wmissing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • This will become an error by default in a future GHC release; use -Werror=severe to make severe warnings into errors now.

Then in a future release:

M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • Use -Wwarn=missing-methods to permit this anyway.

Would that be a reasonable compromise?

Adam

On 19/09/2023 22:13, Joachim Breitner wrote:

...

Hi,

Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:

...

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.

anyone using `-Werror` would already get this behavior. So what is the useful for using `-Werror=severe` instead? Presumably the rationale is:

-Werror, while great _during_ development or in leaf packages, is not is not good idea in _released_ code, i.e. code that is compiled by others, as that code needs to keep working even as compilers and dependencies change, such as libraries on hackage, or executables built by distro packagers. That’s why -Werror is frowned upon there.

But some changes in upstream packages _ought_ to cause compilation to fail, because they really need downstream code changes. These will cause severe warnings, and therefore -Werror=severe is desirable even for released code.

Is that a good way of phrasing your thoughts there?

It looks reasonable to me; if we think of deferable type error as severe warnings, it totally fits this description: It would be _possible_ to keep compiling the downstream code, but it would not be desirable. That's why compilation fails, and that’s why we don’t defer type errors by default.

But if -Werror=severe is desirable generally, it would be unfortunate if we cannot make it the default. If not right away, then maybe with a suitable migration strategy? (Although I wonder if there are many users out there that pay attention to deprecation warnings, e.g. watch -Wdeprecation, that would not have already fixed -Wdefault warnings about missing fields/methods already…)

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I will mull on the actual proposal (I feel there is a solution somewhere here that we haven't hit yet), but I wanted to respond to Simon M's comment about deferred cost: The migration cycle is more than just a deferment: it's a smearing. That is, if something breaks suddenly, everyone must upgrade in unison: hard. If something breaks slowly, then people can update their projects when they choose during the migration period: much easier. That difference might not affect an enterprise all that much, but I think it has a sizable impact on open-source developers. Richard

On Sep 21, 2023, at 8:34 AM, Simon Marlow wrote:

I might be an outlier here, but deferring the change to a later release and adding an intermediate warning doesn't make it any less bad.

This is one cultural aspect of our community I'd like to shift: the expectation that it's OK to make breaking changes as long as you warn about them or go through a migration cycle. It just isn't! (and I speak as someone who used to make lots of changes, I'm now fully repentant!). That's not to say that we shouldn't ever change anything, but when considering the cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it just defers it.

Cheers Simon

On Wed, 20 Sept 2023 at 08:25, Adam Gundry mailto:adam@well-typed.com> wrote: I agree with Joachim's position here.

Having a -Wsevere group at all would be a good start, but the problem with stopping at "best-practice guidance" rather than changing the defaults is that it benefits only those who learn about and follow the guidance. So it remains a footgun for newcomers.

Regarding migration, given that GHC has issued these warnings by default for some time, I don't think we need be too shy about upgrading their severity. We could have -Wcompat imply -Werror=severe, but that complicates the semantics of warning groups, and will help only those who use -Wcompat but don't fix warnings that occur with -Wdefault.

I suppose as Moritz suggests we could introduce and advertise -Wsevere in 9.10, and mention in the warning message that this will be an error in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so 9.10 would give something like:

M.hs:8:10: warning: [-Wmissing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • This will become an error by default in a future GHC release; use -Werror=severe to make severe warnings into errors now.

Then in a future release:

M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • Use -Wwarn=missing-methods to permit this anyway.

Would that be a reasonable compromise?

Adam

On 19/09/2023 22:13, Joachim Breitner wrote:

...

Hi,

Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:

...

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.

anyone using `-Werror` would already get this behavior. So what is the useful for using `-Werror=severe` instead? Presumably the rationale is:

-Werror, while great _during_ development or in leaf packages, is not is not good idea in _released_ code, i.e. code that is compiled by others, as that code needs to keep working even as compilers and dependencies change, such as libraries on hackage, or executables built by distro packagers. That’s why -Werror is frowned upon there.

But some changes in upstream packages _ought_ to cause compilation to fail, because they really need downstream code changes. These will cause severe warnings, and therefore -Werror=severe is desirable even for released code.

Is that a good way of phrasing your thoughts there?

It looks reasonable to me; if we think of deferable type error as severe warnings, it totally fits this description: It would be _possible_ to keep compiling the downstream code, but it would not be desirable. That's why compilation fails, and that’s why we don’t defer type errors by default.

But if -Werror=severe is desirable generally, it would be unfortunate if we cannot make it the default. If not right away, then maybe with a suitable migration strategy? (Although I wonder if there are many users out there that pay attention to deprecation warnings, e.g. watch -Wdeprecation, that would not have already fixed -Wdefault warnings about missing fields/methods already…)

Cheers, Joachim

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ 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@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Just to provide backing to your claim @Simon Marlow , yes it is the same for us 8.10 -> 9.2 -> 9.6, we might effectively go 8.10 -> 9.6 due to performance regressions in 9.2. However, we do use a large part of the hackage ecosystem, and various people _do_ use compilers other than our production compiler in their respective projects CI setup. Thus they _do_ see deprecations, and necessary migrations, _and_ also fix up dependencies in the ecosystem. Thus the cost of upgrading is spread across multiple people and a longer time horizon than trying to upgrade a rather large _living_ codebase at once, by a small "upgrade" team. I also believe that if switching out the compiler was more trivial, we'd be trialing newer compilers much more frequently and quicker, and would be adopting new compilers more frequently. After all, we contribute to those compilers and would like to make use of our own contributions, instead of having to backport them all the time. On Fri, 22 Sept 2023 at 18:36, Simon Marlow wrote:

On Thu, 21 Sept 2023 at 13:51, Richard Eisenberg wrote:

...

I will mull on the actual proposal (I feel there is a solution somewhere here that we haven't hit yet), but I wanted to respond to Simon M's comment about deferred cost: The migration cycle is more than just a deferment: it's a smearing. That is, if something breaks suddenly, everyone must upgrade in unison: hard. If something breaks slowly, then people can update their projects when they choose during the migration period: much easier. That difference might not affect an enterprise all that much, but I think it has a sizable impact on open-source developers.

Yes you're right, and I'm reluctant to further derail this thread but I think it's important to note that as the volume of changes increases, the cost of upgrades increases with it, and so the frequency of upgrades reduces, which nullifies the benefits of smearing the cost of a change with deprecations. Eventually, some customers are jumping over so many releases at once that they miss all the intermediate deprecations. This is the reality where I work, and I believe other companies too.

Cheers Simon

...

Richard

On Sep 21, 2023, at 8:34 AM, Simon Marlow wrote:

I might be an outlier here, but deferring the change to a later release and adding an intermediate warning doesn't make it any less bad.

This is one cultural aspect of our community I'd like to shift: the expectation that it's OK to make breaking changes as long as you warn about them or go through a migration cycle. It just isn't! (and I speak as someone who used to make lots of changes, I'm now fully repentant!). That's not to say that we shouldn't ever change anything, but when considering the cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it just defers it.

Cheers Simon

On Wed, 20 Sept 2023 at 08:25, Adam Gundry wrote:

...

I agree with Joachim's position here.

Having a -Wsevere group at all would be a good start, but the problem with stopping at "best-practice guidance" rather than changing the defaults is that it benefits only those who learn about and follow the guidance. So it remains a footgun for newcomers.

Regarding migration, given that GHC has issued these warnings by default for some time, I don't think we need be too shy about upgrading their severity. We could have -Wcompat imply -Werror=severe, but that complicates the semantics of warning groups, and will help only those who use -Wcompat but don't fix warnings that occur with -Wdefault.

I suppose as Moritz suggests we could introduce and advertise -Wsevere in 9.10, and mention in the warning message that this will be an error in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so 9.10 would give something like:

M.hs:8:10: warning: [-Wmissing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • This will become an error by default in a future GHC release; use -Werror=severe to make severe warnings into errors now.

Then in a future release:

M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • Use -Wwarn=missing-methods to permit this anyway.

Would that be a reasonable compromise?

Adam

On 19/09/2023 22:13, Joachim Breitner wrote:

...

Hi,

Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:

...

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.

anyone using `-Werror` would already get this behavior. So what is the useful for using `-Werror=severe` instead? Presumably the rationale is:

-Werror, while great _during_ development or in leaf packages, is not is not good idea in _released_ code, i.e. code that is compiled by others, as that code needs to keep working even as compilers and dependencies change, such as libraries on hackage, or executables built by distro packagers. That’s why -Werror is frowned upon there.

But some changes in upstream packages _ought_ to cause compilation to fail, because they really need downstream code changes. These will cause severe warnings, and therefore -Werror=severe is desirable even for released code.

Is that a good way of phrasing your thoughts there?

It looks reasonable to me; if we think of deferable type error as severe warnings, it totally fits this description: It would be _possible_ to keep compiling the downstream code, but it would not be desirable. That's why compilation fails, and that’s why we don’t defer type errors by default.

But if -Werror=severe is desirable generally, it would be unfortunate if we cannot make it the default. If not right away, then maybe with a suitable migration strategy? (Although I wonder if there are many users out there that pay attention to deprecation warnings, e.g. watch -Wdeprecation, that would not have already fixed -Wdefault warnings about missing fields/methods already…)

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Dear GHC SC I'd love to know your views about the proposed "General Rules" described here: https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218... If we knew our stance on these, it might help with our debate about the particular proposal #571. Thanks Simon On Thu, 21 Sept 2023 at 14:13, Moritz Angermann wrote:

Thank you Simon!

I think this raises a good point, in that _any_ breaking change should stand well on its own wrt to a cost/benefit analysis.

I’m not sure if we disagree or not. I’ve assumed that the majority wants to make these changes. I also often do not feel sufficiently capable enough to make a convincing argument against a specific change.

Thus under the assumption that we are going to make a breaking change (because the majority want this), I feel very strongly about informing end users beforehand as well as the quality control aspect of being able to run regression tests by just swapping out the compiler trivially.

Thus *if* we are making a breaking change, I do not believe that a migration phase reduces the costs much (you still need to adjust your code), but I consider a breaking change without migration phase to be significantly worse to a breaking change with migration phase.

The difference for me practically lies in the following: If we migrate to a new compiler, a team of engineers start doing the initial migration for us (this means adding the new compiler to CI, and making sure existing code at least builds), this happens for multiple projects/components in dependency order.

After this has happened the project/component teams use the new compiler and fix their code.

If we have migration warnings for upcoming breaking changes, the work shifts from the new-compiler-across-multiple-projects team into the project teams.

This makes the whole add new compiler process significantly faster, and means less friction. It also means the project teams who have much better knowledge of their specific project can address the warnings better than the migration team which has to dig deep into existing code bases, get familiar with the code to make the necessity adjustments (or request pair sessions that take time from other tasks).

It also gives one more opportunity for the community to raise their hand and say, oh hell no, that’s a stupid idea; I’m going to complain about this! (I’ve been told this more than once; migration phases could also be seen as community inquiery, to get feedback from actual practitioners).

After writing this all down, I guess my push for “if breaking change, then only with migration phase” is orthogonal to “should we have breaking changes to begin with?”

Cheers, Moritz

On Thu, 21 Sep 2023 at 8:35 PM, Simon Marlow wrote:

...

I might be an outlier here, but deferring the change to a later release and adding an intermediate warning doesn't make it any less bad.

This is one cultural aspect of our community I'd like to shift: the expectation that it's OK to make breaking changes as long as you warn about them or go through a migration cycle. It just isn't! (and I speak as someone who used to make lots of changes, I'm now fully repentant!). That's not to say that we shouldn't ever change anything, but when considering the cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it just defers it.

Cheers Simon

On Wed, 20 Sept 2023 at 08:25, Adam Gundry wrote:

...

I agree with Joachim's position here.

Having a -Wsevere group at all would be a good start, but the problem with stopping at "best-practice guidance" rather than changing the defaults is that it benefits only those who learn about and follow the guidance. So it remains a footgun for newcomers.

Regarding migration, given that GHC has issued these warnings by default for some time, I don't think we need be too shy about upgrading their severity. We could have -Wcompat imply -Werror=severe, but that complicates the semantics of warning groups, and will help only those who use -Wcompat but don't fix warnings that occur with -Wdefault.

I suppose as Moritz suggests we could introduce and advertise -Wsevere in 9.10, and mention in the warning message that this will be an error in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so 9.10 would give something like:

M.hs:8:10: warning: [-Wmissing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • This will become an error by default in a future GHC release; use -Werror=severe to make severe warnings into errors now.

Then in a future release:

M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • Use -Wwarn=missing-methods to permit this anyway.

Would that be a reasonable compromise?

Adam

On 19/09/2023 22:13, Joachim Breitner wrote:

...

Hi,

Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:

...

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.

anyone using `-Werror` would already get this behavior. So what is the useful for using `-Werror=severe` instead? Presumably the rationale is:

-Werror, while great _during_ development or in leaf packages, is not is not good idea in _released_ code, i.e. code that is compiled by others, as that code needs to keep working even as compilers and dependencies change, such as libraries on hackage, or executables built by distro packagers. That’s why -Werror is frowned upon there.

But some changes in upstream packages _ought_ to cause compilation to fail, because they really need downstream code changes. These will cause severe warnings, and therefore -Werror=severe is desirable even for released code.

Is that a good way of phrasing your thoughts there?

It looks reasonable to me; if we think of deferable type error as severe warnings, it totally fits this description: It would be _possible_ to keep compiling the downstream code, but it would not be desirable. That's why compilation fails, and that’s why we don’t defer type errors by default.

But if -Werror=severe is desirable generally, it would be unfortunate if we cannot make it the default. If not right away, then maybe with a suitable migration strategy? (Although I wonder if there are many users out there that pay attention to deprecation warnings, e.g. watch -Wdeprecation, that would not have already fixed -Wdefault warnings about missing fields/methods already…)

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I agree with Chris and Simon M. I would probably support turning these warnings into errors as part of the next GHC20XX standard, but not as an isolated one-off change. On Fri, Sep 22, 2023, at 07:16, Chris Dornan wrote:

Moritz, can I pass on some excellent advice I got from Richard on first joining the list, namely don't try to 'read the room' here but call things as you see them. Thanks to some excellent management from the usual suspects we are quite good at searching out a consensus when needed.

I am strongly in agreement with Simon Marlow here -- I really don't think we should be introducing breaking changes unless it is really, really necessary, and I just don't think "this is what we think developers should be doing" and "nobody reads manuals any more" clears the threshold for me. And, while I take Richard's point about the value of deprecation periods, I still think we should only introduce breaking changes in exceptional circumstances.

Again, I fully support the introduction of the Severe category with the proposed warnings included.

The way I would approach this is to predicate the change of behaviour on a language extension with a view to getting it included in (say) GHC2024. People that really care about stability can tie things down by specifying the language they are working with at the appropriate points. Folks are now used to the GHC selecting a new default once a new Haskell* or GHC* standard is agreed.

Chris

...

On 21 Sep 2023, at 14:13, Moritz Angermann wrote:

Thank you Simon!

I think this raises a good point, in that _any_ breaking change should stand well on its own wrt to a cost/benefit analysis.

I’m not sure if we disagree or not. I’ve assumed that the majority wants to make these changes. I also often do not feel sufficiently capable enough to make a convincing argument against a specific change.

Thus under the assumption that we are going to make a breaking change (because the majority want this), I feel very strongly about informing end users beforehand as well as the quality control aspect of being able to run regression tests by just swapping out the compiler trivially.

Thus *if* we are making a breaking change, I do not believe that a migration phase reduces the costs much (you still need to adjust your code), but I consider a breaking change without migration phase to be significantly worse to a breaking change with migration phase.

The difference for me practically lies in the following: If we migrate to a new compiler, a team of engineers start doing the initial migration for us (this means adding the new compiler to CI, and making sure existing code at least builds), this happens for multiple projects/components in dependency order.

After this has happened the project/component teams use the new compiler and fix their code.

If we have migration warnings for upcoming breaking changes, the work shifts from the new-compiler-across-multiple-projects team into the project teams.

This makes the whole add new compiler process significantly faster, and means less friction. It also means the project teams who have much better knowledge of their specific project can address the warnings better than the migration team which has to dig deep into existing code bases, get familiar with the code to make the necessity adjustments (or request pair sessions that take time from other tasks).

It also gives one more opportunity for the community to raise their hand and say, oh hell no, that’s a stupid idea; I’m going to complain about this! (I’ve been told this more than once; migration phases could also be seen as community inquiery, to get feedback from actual practitioners).

After writing this all down, I guess my push for “if breaking change, then only with migration phase” is orthogonal to “should we have breaking changes to begin with?”

Cheers, Moritz

On Thu, 21 Sep 2023 at 8:35 PM, Simon Marlow wrote:

...

I might be an outlier here, but deferring the change to a later release and adding an intermediate warning doesn't make it any less bad.

This is one cultural aspect of our community I'd like to shift: the expectation that it's OK to make breaking changes as long as you warn about them or go through a migration cycle. It just isn't! (and I speak as someone who used to make lots of changes, I'm now fully repentant!). That's not to say that we shouldn't ever change anything, but when considering the cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it just defers it.

Cheers Simon

On Wed, 20 Sept 2023 at 08:25, Adam Gundry wrote:

...

I agree with Joachim's position here.

Having a -Wsevere group at all would be a good start, but the problem with stopping at "best-practice guidance" rather than changing the defaults is that it benefits only those who learn about and follow the guidance. So it remains a footgun for newcomers.

Regarding migration, given that GHC has issued these warnings by default for some time, I don't think we need be too shy about upgrading their severity. We could have -Wcompat imply -Werror=severe, but that complicates the semantics of warning groups, and will help only those who use -Wcompat but don't fix warnings that occur with -Wdefault.

I suppose as Moritz suggests we could introduce and advertise -Wsevere in 9.10, and mention in the warning message that this will be an error in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so 9.10 would give something like:

M.hs:8:10: warning: [-Wmissing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • This will become an error by default in a future GHC release; use -Werror=severe to make severe warnings into errors now.

Then in a future release:

M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods] • No explicit implementation for ‘<>’ • In the instance declaration for ‘Semigroup T’ • Warning: this may lead to an infinite loop or runtime exception. • Use -Wwarn=missing-methods to permit this anyway.

Would that be a reasonable compromise?

Adam

On 19/09/2023 22:13, Joachim Breitner wrote:

...

Hi,

Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:

...

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.

anyone using `-Werror` would already get this behavior. So what is the useful for using `-Werror=severe` instead? Presumably the rationale is:

-Werror, while great _during_ development or in leaf packages, is not is not good idea in _released_ code, i.e. code that is compiled by others, as that code needs to keep working even as compilers and dependencies change, such as libraries on hackage, or executables built by distro packagers. That’s why -Werror is frowned upon there.

But some changes in upstream packages _ought_ to cause compilation to fail, because they really need downstream code changes. These will cause severe warnings, and therefore -Werror=severe is desirable even for released code.

Is that a good way of phrasing your thoughts there?

It looks reasonable to me; if we think of deferable type error as severe warnings, it totally fits this description: It would be _possible_ to keep compiling the downstream code, but it would not be desirable. That's why compilation fails, and that’s why we don’t defer type errors by default.

But if -Werror=severe is desirable generally, it would be unfortunate if we cannot make it the default. If not right away, then maybe with a suitable migration strategy? (Although I wonder if there are many users out there that pay attention to deprecation warnings, e.g. watch -Wdeprecation, that would not have already fixed -Wdefault warnings about missing fields/methods already…)

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I'm inclined to follow Adam and make -Werror=severe the default immediately. But I don't feel strongly about it. On Fri, 29 Sept 2023 at 20:41, Adam Gundry 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-... ):

...

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-s...

...

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-s...

...

...

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

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 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 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-... ):

...

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-s...

...

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

...

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

it 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-s...

...

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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 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@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 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-... ):

...

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-s...

...

This is primarily motivated by the fact that when classes have

...

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

default 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-s...

...

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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 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@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 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@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 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-... ):

> 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-s... > > 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-s... >> >> 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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 mailto:simon.peytonjones@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 mailto:marlowsd@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 mailto:simon.peytonjones@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 mailto:adam@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-... https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-...):

 > 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-s... https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-s... > > 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-s... https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-s... >> >> 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

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 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, mailto:adam@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 mailto:simon.peytonjones@gmail.com mailto:simon.peytonjones@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 mailto:marlowsd@gmail.com mailto:marlowsd@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 mailto:simon.peytonjones@gmail.com mailto:simon.peytonjones@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 mailto:adam@well-typed.com mailto:adam@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-... https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-...):

> 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-s... https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-s... > > 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-s... https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-s... >> >> 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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 mailto:chris@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 mailto:marlowsd@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, mailto:adam@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 mailto:simon.peytonjones@gmail.com mailto:simon.peytonjones@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 mailto:marlowsd@gmail.com mailto:marlowsd@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 mailto:simon.peytonjones@gmail.com mailto:simon.peytonjones@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 mailto:adam@well-typed.com mailto:adam@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-... https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-...):

> 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-s... https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-s... > > 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-s... https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-s... >> >> 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@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I am trying to not be prescriptive. If I were writing the proposal I would leave it as it is, but simply add a language extension (NoSevereWarnings say), that make -Werror=severe the default. I would then add NoSevereWarnings to GHC2024 ready for it to become the default out-of-the-box behaviour in GHC9.10 (say) without any need for deprecation cycles. Chris

On 9 Oct 2023, at 10:18, Simon Peyton Jones wrote:

OK so concretely you are saying Expressing support for the general rules in the draft GHC stability policy https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47Zulga.... 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 mailto:chris@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 mailto:simon.peytonjones@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 mailto:chris@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 mailto:marlowsd@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, mailto:adam@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 > mailto:simon.peytonjones@gmail.com mailto:simon.peytonjones@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 mailto:marlowsd@gmail.com > mailto:marlowsd@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 > mailto:simon.peytonjones@gmail.com > mailto:simon.peytonjones@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 > mailto:adam@well-typed.com mailto:adam@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-... https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-...): > > > 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-s... https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-s... > > > > 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-s... https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-s... > >> > >> 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@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Montag, dem 09.10.2023 um 12:25 +0100 schrieb Simon Marlow:

By putting the new behaviour in GHC2024, users can choose when to update their code to accommodate the change.

almost. Users choose when to update _their_ code to a new language edition, but not when their dependencies are updated. For most proposals, I’d fully agree that going via a new language extension, possibly on by default in a future GHC20xx, is the way to go. But in this _particular_ case, we have that the main driving motivation is that we really want libraries to stop building if their dependencies have introduced new methods. These libraries are very likely not going to use GHC2024 any time soon:  Firstly, because libraries can’t upgrade to new GHC20xx as quickly as programs can, because they want to support older versions of GHC. But secondly, because this quality control of “build fails when things are likely wrong” is especially important for less-actively maintained libraries. Changes tied to language pragmas only affect those modules/libraries that want to be affected. This is great in general, but not helpful for changes that need to apply to _all_ modules/libraries. So it seems that the present use case is only well addressed if `- Werror=missing-methods` becomes a default in a future GHC version _independent_ of the language model. The stability document has a provision vor this:

(GR2) We may break (GR1), but only with a compelling reason, and with careful consideration of impact..

I suggest we first focus on this question: Does the proposed change should fall under this exception and be rolled out (with deprecation) globally. If yes, we do that. If not, we can then ponder if this change is still useful as part of a future GHC20xx, or not worth the bother then. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi, Am Montag, dem 09.10.2023 um 21:04 +0800 schrieb Moritz Angermann:

Joachim,

...

the main driving motivation is that we really want libraries to stop building if their dependencies have introduced new methods.

So we want this because we introduce extra fields in a dependency and thus "silently" break all consumers? Not because people write new green-field code and end up ignoring the warning?

That is my understanding, yes. Oleg, who suggested this originally (I just wrote it up) says (see motivation section of the proposal)

not having -Wsevere=missing-methods by default essentially prevents  any (true) breakage assessment of adding new, non-defaulted members to existing type-classes.

Wouldn't this be something that PVP should guard against? Adding new fields should result in a new major version, because it's technically a breaking change?

Yeah, probably in a world where everyone follows the PVP perfectly, we wouldn’t have this discussion. Am Montag, dem 09.10.2023 um 14:38 +0100 schrieb Chris Dornan:

If I understand you rightly, you are arguing that any legacy packages that would flag severe warnings should now fail to compile, even if  they are marked as being (say) Haskell2010?

I’m not arguing that we should do this, but I am arguing that this is the question we are supposed to decide here. (I’m personally not decided

If the impetus for the proposal was driven by observed problematic failures of packaged code that could be caught by these warnings then, for me, there would be a discussion to be had.

My understanding, based on the motivation section, is that this _is_ the impetus. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

On Mon, 9 Oct 2023 at 15:22, Joachim Breitner wrote:

That is my understanding, yes. Oleg, who suggested this originally (I just wrote it up) says (see motivation section of the proposal)

...

not having -Wsevere=missing-methods by default essentially prevents any (true) breakage assessment of adding new, non-defaulted members to existing type-classes.

If the goal is to do a breakage assessment, couldn't you make the change to your library and then build all of Hackage with `--ghc-option=-Werror=severe`? Cheers Simon

...

Wouldn't this be something that PVP should guard against? Adding new fields should result in a new major version, because it's technically a breaking change?

Yeah, probably in a world where everyone follows the PVP perfectly, we wouldn’t have this discussion.

Am Montag, dem 09.10.2023 um 14:38 +0100 schrieb Chris Dornan:

...

If I understand you rightly, you are arguing that any legacy packages that would flag severe warnings should now fail to compile, even if they are marked as being (say) Haskell2010?

I’m not arguing that we should do this, but I am arguing that this is the question we are supposed to decide here. (I’m personally not decided

...

If the impetus for the proposal was driven by observed problematic failures of packaged code that could be caught by these warnings then, for me, there would be a discussion to be had.

My understanding, based on the motivation section, is that this _is_ the impetus.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

This all sounds to me like we are trying to fix PVP by adding errors. I'm ok to declare PVP bankruptcy. If it's too hard to be practically used, we need to find a different solution. But this problem to me sounds more like we rather need some automation? What we seem to essentially want to achieve is guarantee that component integration is not faulty? It all sounds to me like what we really want is an automated solution that flags packages that were broken by changes in their dependencies. And then be trivially able to address those (and open PRs). Though I guess you'd also need to deal with version bounds, the inverse of missing-fields would be overspecified fields, and thus the library that depends on something that added more fields, now needs a hard lower bound after adding the fields? https://github.com/ghc-proposals/ghc-proposals/pull/617 likely also would benefit from automation. Maybe reboot hackage matrix in some form? Can someone point me in the right direction? Best, Moritz On Mon, 9 Oct 2023 at 23:57, Joachim Breitner wrote:

Hi,

Am Montag, dem 09.10.2023 um 16:53 +0100 schrieb Simon Marlow:

...

On Mon, 9 Oct 2023 at 15:22, Joachim Breitner wrote:

...

That is my understanding, yes. Oleg, who suggested this originally (I just wrote it up) says (see motivation section of the proposal)

...

not having -Wsevere=missing-methods by default essentially prevents any (true) breakage assessment of adding new, non-defaulted members to existing type-classes.

If the goal is to do a breakage assessment, couldn't you make the change to your library and then build all of Hackage with `--ghc- option=-Werror=severe`?

Not if Hackage already fails with -Werror=severe even without the change under assessment. But we should ask Oleg on Github, I am just relaying what I thought his motivation was.

Should we send this back for revision? It seems there is plenty of discussion going on here and on github. (Is there an equivalent of Wadler’s law about “compiler flags” instead of “whitespace”?)

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

If I understand you rightly, you are arguing that any legacy packages that would flag severe warnings should now fail to compile, even if they are marked as being (say) Haskell2010? For reasons I have given (I have no wish to be repetive), that strikes me as undesirable. If the impetus for the proposal was driven by observed problematic failures of packaged code that could be caught by these warnings then, for me, there would be a discussion to be had. But my understanding is that the proposal is driven by a desire to tighten up the language moving forward with severe warnings treated as errors by default. Maybe one of the authors could say which they intended. Chris

On 9 Oct 2023, at 13:16, Joachim Breitner wrote:

Hi,

Am Montag, dem 09.10.2023 um 12:25 +0100 schrieb Simon Marlow:

...

By putting the new behaviour in GHC2024, users can choose when to update their code to accommodate the change.

almost. Users choose when to update _their_ code to a new language edition, but not when their dependencies are updated.

For most proposals, I’d fully agree that going via a new language extension, possibly on by default in a future GHC20xx, is the way to go. But in this _particular_ case, we have that the main driving motivation is that we really want libraries to stop building if their dependencies have introduced new methods. These libraries are very likely not going to use GHC2024 any time soon:

Firstly, because libraries can’t upgrade to new GHC20xx as quickly as programs can, because they want to support older versions of GHC.

But secondly, because this quality control of “build fails when things are likely wrong” is especially important for less-actively maintained libraries.

Changes tied to language pragmas only affect those modules/libraries that want to be affected. This is great in general, but not helpful for changes that need to apply to _all_ modules/libraries.

So it seems that the present use case is only well addressed if `- Werror=missing-methods` becomes a default in a future GHC version _independent_ of the language model. The stability document has a provision vor this:

...

(GR2) We may break (GR1), but only with a compelling reason, and with careful consideration of impact..

I suggest we first focus on this question: Does the proposed change should fall under this exception and be rolled out (with deprecation) globally. If yes, we do that. If not, we can then ponder if this change is still useful as part of a future GHC20xx, or not worth the bother then.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee