I think Herbert was proposing adding a -Wcompat flag to use to get all warnings of known pending changes, even ones where action now can't be taken without CPP. e.g. for 8.0 this would include the warnings for the MonadFail proposal, etc. -Edward On Tue, Oct 20, 2015 at 5:02 PM, Richard Eisenberg wrote:

I share this concern. I think one way to keep folks happy is to have multiple tiers of warnings. Then library authors can aim to have their libraries warning-free up to some tier.

I wonder if part of the problem is that Haskell is optimized for programmers who prize beauty and cleanliness. Warnings are ugly! So our community avoids them at all cost... and that cost seems to have gotten too high. Engineering is sometimes dirty, and we shouldn't be ashamed of that.

Richard

On Oct 20, 2015, at 3:55 PM, Jeremy wrote:

...

A "3 release policy" has been recently mentioned several times, whereby it should always be possible to write code that compiles with the last three releases of GHC, without generating any -Wall warnings.

The no warning requirement seems excessively harsh. Will early warnings of impending breakage really cause so much trouble that accepted proposals have to be dragged out over several years to avoid them? If so, would a flag to suppress the warnings suffice?

I should note that GHC has traditionally had no qualms about introducing new warnings, on by default.

-- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-tp5820363.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Wed, Oct 21, 2015 at 12:23 AM, Vincent Hanquez wrote:

On 20/10/2015 22:12, Edward Kmett wrote:

...

I think Herbert was proposing adding a -Wcompat flag to use to get all warnings of known pending changes, even ones where action now can't be taken without CPP.

e.g. for 8.0 this would include the warnings for the MonadFail proposal, etc.

Some other warnings like 'unused-imports' don't make much sense on by default with -Wall. This warning is only useful for linting purpose, and clearly doesn't fall in the same category as other useful ones.

That would remove the need for a lot of CPP that got added in the 7.10 era, like:

#if ... import Control.Applicative #end

-- Vincent

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

+1

On Tue, Oct 20, 2015 at 5:48 PM, Mark Lentczner wrote:

Pretty much every shop I've worked at for the last 30 years has had a "must compile clean with no warnings" policy, no matter the language. The reason

That's actually not true for java at google. However, after warning bankruptcy was declared, a small set were made into errors and the rest suppressed. So that supports the idea of categorizing warnings into serious and advisory, and using -Werror only for serious ones. Of course, choosing which ones are which is likely to be a wrangle. In my personal code I do the same, that is try to make it warning free but only enable warnings that I consider worthwhile. It would also be really nice to have pragmas to suppress warnings locally (e.g. ErrorT deprecation warnings from transformers-4, which seem to be impossible to fix without abandoning 7.8).

...

...

...

...

Simon Peyton Jones writes:

I'd love to find a way to make warnings more supple, less of a blunt instrument. It hurts me that what is intended as a gentle hint actually ends up disrupting our entire ecosystem!

Since warnings are intended to mean "This could be a problem, but might not be, be warned", there should be a case-by-case way of answering it and saying "I know this isn't a problem". I think a pragma for disabling a particular warning at certain code location would be a good addition to our current disabling mechanisms? John

I hope we *will* have an option to warn about that. But not by default, I agree! On Wed, Oct 21, 2015 at 10:40 PM, M Farkas-Dyck wrote:

On 21/10/2015, John Wiegley wrote:

...

Since warnings are intended to mean "This could be a problem, but might not be, be warned", there should be a case-by-case way of answering it and saying "I know this isn't a problem". I think a pragma for disabling a particular warning at certain code location would be a good addition to our current disabling mechanisms?

I hope we won't warn about unused warning suppression... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

+1 to be able to suppress warnings locally. This would allow to suppress a warning that I know is OK at that place, without suppressing the same kind of warnings elsewhere where they might be important. Dne st 21. 10. 2015 3:06 uživatel Evan Laforge napsal:

On Tue, Oct 20, 2015 at 5:48 PM, Mark Lentczner wrote:

...

Pretty much every shop I've worked at for the last 30 years has had a "must compile clean with no warnings" policy, no matter the language. The reason

That's actually not true for java at google. However, after warning bankruptcy was declared, a small set were made into errors and the rest suppressed. So that supports the idea of categorizing warnings into serious and advisory, and using -Werror only for serious ones. Of course, choosing which ones are which is likely to be a wrangle.

In my personal code I do the same, that is try to make it warning free but only enable warnings that I consider worthwhile. It would also be really nice to have pragmas to suppress warnings locally (e.g. ErrorT deprecation warnings from transformers-4, which seem to be impossible to fix without abandoning 7.8). _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

I think Petr was suggesting (either way, I am!) that you should be able to suppress a warning for only one identifier, or only one location. * I don't want to enable IncoherentInstances for my whole module because then I might mess up, only for this one instance * I don't want to allow all orphan instances, only this one instance * I don't want to hide all possible future and past deprecation warnings, I only want to mark this one identifier as ok for compatibility reasons ... et.c. Cheers, Adam On Wed, Oct 21, 2015 at 1:51 PM, evan@evan-borden.com < evan@evanrutledgeborden.dreamhosters.com> wrote:

...

+1 to be able to suppress warnings locally.

Isn't this already possible with the OPTIONS_GHC pragma?

{-# OPTIONS_GHC -fnowarn-____ #-}

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Wed, Oct 21, 2015 at 2:13 PM, Adam Bergmark wrote:

I think Petr was suggesting (either way, I am!) that you should be able to suppress a warning for only one identifier, or only one location.

See https://ghc.haskell.org/trac/ghc/ticket/602 ("Warning Suppression").