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.haskell.org/trac/ghc/wiki/Design/Warnings Cheers, Gershom On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlo...@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://prime.haskell.org/wiki/Libraries/3-Release-Policy) 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 > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
