Thanks Gershom. That all sounds fine to me. An implication is that GHC is free to introduce new warnings X into -Wall. Indeed doing so would be good, because the warning X might later move into the default set. Indeed for such warnings, adding a "PS: this warning will become the default in GHC 9.2" might be a useful way to signal the upcoming change. Then you can use -Wall and look for any "PS" indicators. You don’t give a rationale for (2) but I think you intend that if someone wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to fall over. Worth articulating the rationale. Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Gershom B | Sent: 13 January 2016 02:20 | To: GHC users ; ghc-devs@haskell.org; | Edward Kmett ; Herbert Valerio Riedel ; Simon | Marlow | Subject: Re: Warnings, -Wall, and versioning policy | | Hi Simon. I think you raise important issues here, although I believe you’re | mistaken in one regard. Hackage rejects -Werror but I don’t think it rejects | -Wall. | |  What I’d suggest is perhaps the following. | | 1) The libraries committee put forward -Wall cleanliness as an _aspirational | goal_ rather than a final product, noting that the actual cleanliness might | be with regards to `-Wall -Wno-foo -Wno-bar``. | | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather | than an _error_ on `-W` followed by an unrecognized string. | | 3) No warning flags be introduced into the _default_ set without at least a | few releases in some other set such as `-Wall`. | | We may also want to try to maintain a “best practices” example cabal file | that shows how one can build with additional warnings under a “dev” flag, and | with fewer warnings otherwise — so that the noise inflicted on package devs | under their builds doesn’t get inflicted on all end users, and even perhaps | with different warning flags per ghc version flag. | | I think this will respect the concerns of people that like to use `-Wall`, | want to have relatively warning clean code, and want to have some degree of | backwards compatibility (which is not an unreasonable combination in my | opinion). | | Some related | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and https://ghc.has | kell.org/trac/ghc/wiki/Design/Warnings | | Cheers, | Gershom | | | On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd@gmail.com) wrote: | > Hi folks, | > | > We haven't described what guarantees GHC provides with respect to -Wall | > behaviour across versions, and as a result there are some differing | > expectations around this. It came up in this weeks' GHC meeting, so we | > thought it would be a good idea to state the policy explicitly. Here it is: | > | > We guarantee that code that compiles with no warnings with -Wall | > ("Wall-clean") and a particular GHC version, on a particular | > platform, will be Wall-clean with future minor releases of the same | > major GHC version on the same platform. | > | > (we plan to put this text in the User's Guide for future releases) | > | > There are no other guarantees. In particular: | > - In a new major release, GHC may introduce new warnings into -Wall, | > and/or change the meaning of existing warnings such that they trigger | > (or not) under different conditions. | > - GHC may generate different warnings on different platforms. (examples | > of this are -fwarn-overflowed-literals and | > -fwarn-unsupported-calling-conventions) | > | > Some rationale: | > - We consider any change to the language that GHC accepts to be a | > potentially code-breaking change, and subject to careful scrutiny. To | > extend this to warnings would be a *lot* of work, and would make it | > really difficult to introduce new warnings and improve the existing ones. | > - Warnings can be based on analyses that can change in accuracy over | > time. The -fwarn-unused-imports warning has changed a lot in what it | > rejects, for example. | > - We often introduce new warnings that naturally belong in -Wall. If | > -Wall was required to be a fixed point, we would have to start | > introducing new flags, and versioning, etc. and even keep the old | > implementation of warnings when they change. It would get really messy. | > | > There are some consequences to this. -Wall -Werror is useful for | > keeping your code warning-clean when developing, but shipping code with | > these options turned on in the build system is asking for trouble when | > building your code with different GHC versions and platforms. Keep | > those options for development only. Hackage already rejects packages | > that include -Wall for this reason. | > | > One reason we're raising this now is that it causes problems for the | > 3-release policy | > | (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske | ll.org%2fwiki%2fLibraries%2f3-Release- | Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263 | 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN | khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which | > requires that it be possible to write code that is Wall-clean with 3 | > major releases of GHC. GHC itself doesn't guarantee this, so it might | > be hard for the core libraries committee to provide this guarantee. I | > suggest this requirement be dropped from the policy. | > | > Cheers, | > Simon | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell- | users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630 | 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo | qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d | > | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell- | users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802 | 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY | fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d

OK. When this thread comes to a conclusion, can someone write it down; update the 3-release policy; and say what changes you want in GHC? Thanks Simon | -----Original Message----- | From: Gershom B [mailto:gershomb@gmail.com] | Sent: 13 January 2016 18:18 | To: Simon Peyton Jones | Cc: GHC users ; ghc-devs@haskell.org; | Edward Kmett ; Herbert Valerio Riedel ; Simon | Marlow | Subject: Re: Warnings, -Wall, and versioning policy | | On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones | wrote: | | > An implication is that GHC is free to introduce new warnings X into -Wall. | Indeed doing so would be good, because the warning X might later move into | the default set. Indeed for such warnings, adding a "PS: this warning will | become the default in GHC 9.2" might be a useful way to signal the upcoming | change. Then you can use -Wall and look for any "PS" indicators. | | Yep. In general I think we don't know how _much_ noise a warning will | create until it makes it into the wild, so just as with other new | features its good to give them a bit of a "dry run" before deciding | that they come "by default." | | > You don’t give a rationale for (2) but I think you intend that if someone | wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to | fall over. Worth articulating the rationale. | | Yes, that's exactly the rationale. It doesn't help us short term, but | longer term it should let users fiddle with warning flags more freely. | | I think the general issue with three releases is not whether or not | GHC introduces warnings and at what pace, but that certain _types_ of | warnings (in particular redundancies, be they constraints, imports, | etc) will fire on entirely desirable code due to certain migration | paths. Most of the tricks we developed for backwards-compatible | migrations essentially depend on certain redundancies in code for a | period. Those can't be removed without hurting backwards-compatibility | of code, but their presence also induces warnings. | | So as a whole "warning freeness" and "backwards compatible migrations" | become increasingly at odds with one another. | | A full refactor of our warning sets would probably help in this | regard, so that the default advice could be "good code is -Wlint clean | but not necessarily -Wpedantic clean". Or even "is clean under | -Wpedantic -Wno-redundancies". | | --Gershom | | > | > | -----Original Message----- | > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | > | bounces@haskell.org] On Behalf Of Gershom B | > | Sent: 13 January 2016 02:20 | > | To: GHC users ; ghc-devs@haskell.org; | > | Edward Kmett ; Herbert Valerio Riedel ; | Simon | > | Marlow | > | Subject: Re: Warnings, -Wall, and versioning policy | > | | > | Hi Simon. I think you raise important issues here, although I believe | you’re | > | mistaken in one regard. Hackage rejects -Werror but I don’t think it | rejects | > | -Wall. | > | | > | What I’d suggest is perhaps the following. | > | | > | 1) The libraries committee put forward -Wall cleanliness as an | _aspirational | > | goal_ rather than a final product, noting that the actual cleanliness | might | > | be with regards to `-Wall -Wno-foo -Wno-bar``. | > | | > | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather | > | than an _error_ on `-W` followed by an unrecognized string. | > | | > | 3) No warning flags be introduced into the _default_ set without at least | a | > | few releases in some other set such as `-Wall`. | > | | > | We may also want to try to maintain a “best practices” example cabal file | > | that shows how one can build with additional warnings under a “dev” flag, | and | > | with fewer warnings otherwise — so that the noise inflicted on package | devs | > | under their builds doesn’t get inflicted on all end users, and even | perhaps | > | with different warning flags per ghc version flag. | > | | > | I think this will respect the concerns of people that like to use `- | Wall`, | > | want to have relatively warning clean code, and want to have some degree | of | > | backwards compatibility (which is not an unreasonable combination in my | > | opinion). | > | | > | Some related | > | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and | https://ghc.has | > | | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fkell.org%2f... | rac%2fghc%2fwiki%2fDesign%2fWarnings&data=01%7c01%7csimonpj%40064d.mgd.micros | oft.com%7c9de7c65d89a84408f00808d31c45e258%7c72f988bf86f141af91ab2d7cd011db47 | %7c1&sdata=BE9pq5knT%2fWTxOfrtEYefqDC2qMEQP%2b9fbcgvs%2f2qr0%3d | Cheers, | > | Gershom | > | | > | | > | On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd@gmail.com) | wrote: | > | > Hi folks, | > | > | > | > We haven't described what guarantees GHC provides with respect to -Wall | > | > behaviour across versions, and as a result there are some differing | > | > expectations around this. It came up in this weeks' GHC meeting, so we | > | > thought it would be a good idea to state the policy explicitly. Here it | is: | > | > | > | > We guarantee that code that compiles with no warnings with -Wall | > | > ("Wall-clean") and a particular GHC version, on a particular | > | > platform, will be Wall-clean with future minor releases of the same | > | > major GHC version on the same platform. | > | > | > | > (we plan to put this text in the User's Guide for future releases) | > | > | > | > There are no other guarantees. In particular: | > | > - In a new major release, GHC may introduce new warnings into -Wall, | > | > and/or change the meaning of existing warnings such that they trigger | > | > (or not) under different conditions. | > | > - GHC may generate different warnings on different platforms. (examples | > | > of this are -fwarn-overflowed-literals and | > | > -fwarn-unsupported-calling-conventions) | > | > | > | > Some rationale: | > | > - We consider any change to the language that GHC accepts to be a | > | > potentially code-breaking change, and subject to careful scrutiny. To | > | > extend this to warnings would be a *lot* of work, and would make it | > | > really difficult to introduce new warnings and improve the existing | ones. | > | > - Warnings can be based on analyses that can change in accuracy over | > | > time. The -fwarn-unused-imports warning has changed a lot in what it | > | > rejects, for example. | > | > - We often introduce new warnings that naturally belong in -Wall. If | > | > -Wall was required to be a fixed point, we would have to start | > | > introducing new flags, and versioning, etc. and even keep the old | > | > implementation of warnings when they change. It would get really messy. | > | > | > | > There are some consequences to this. -Wall -Werror is useful for | > | > keeping your code warning-clean when developing, but shipping code with | > | > these options turned on in the build system is asking for trouble when | > | > building your code with different GHC versions and platforms. Keep | > | > those options for development only. Hackage already rejects packages | > | > that include -Wall for this reason. | > | > | > | > One reason we're raising this now is that it causes problems for the | > | > 3-release policy | > | > | > | | (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske | > | ll.org%2fwiki%2fLibraries%2f3-Release- | > | | Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263 | > | | 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN | > | khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which | > | > requires that it be possible to write code that is Wall-clean with 3 | > | > major releases of GHC. GHC itself doesn't guarantee this, so it might | > | > be hard for the core libraries committee to provide this guarantee. I | > | > suggest this requirement be dropped from the policy. | > | > | > | > Cheers, | > | > Simon | > | > _______________________________________________ | > | > Glasgow-haskell-users mailing list | > | > Glasgow-haskell-users@haskell.org | > | > | > | | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | > | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell- | > | | users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630 | > | | 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo | > | qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d | > | > | > | | > | _______________________________________________ | > | Glasgow-haskell-users mailing list | > | Glasgow-haskell-users@haskell.org | > | | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | > | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell- | > | | users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802 | > | | 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY | > | fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d