3 release policy

[Simon Peyton Jones]

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

Surely warning categorisation *must* be the way to go here.

Warnings vary a *lot* from things where I thought "something might be fishy here; I'd better tell the user", to "really something is almost certainly wrong, but it's legal Haskell so it can't be an error", to "this function is deprecated so at a convenient moment in the next year or two you'd better change it".

If all warnings are treated uniformly as errors that must be eliminated, the merit of having warnings, rather than outright errors, is greatly reduced.  And, speaking from the compiler-writer front, instead of thinking "someone might be interested, so I'll add an optional warning", I have to worry about whether I'm going to cause lots of busy-work for library authors.

Trouble is, any particular categorisation will be slightly wrong for almost everyone.  Would it help if any one organisation could list the warnings that it wanted to hear about (and then eliminate), put that in a .ghc file, OPTIONS pragma, or on the command line?  So, in effect, have a per-org warning categorisation.  (It would make for a very long command line.)

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!

Simon

|  -----Original Message-----
|  From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Evan
|  Laforge
|  Sent: 21 October 2015 02:06
|  To: Mark Lentczner
|  Cc: Haskell Libraries; Jeremy
|  Subject: Re: 3 release policy
|  
|  On Tue, Oct 20, 2015 at 5:48 PM, Mark Lentczner <mark.lentczner at gmail.com>
|  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 at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell
|  .org%2fcgi-
|  bin%2fmailman%2flistinfo%2flibraries&data=01%7c01%7csimonpj%40064d.mgd.micro
|  soft.com%7cbb757c3c4d9740558e7e08d2d9b3dd3b%7c72f988bf86f141af91ab2d7cd011db
|  47%7c1&sdata=6n5N0v39UvgSakYhVRo92PKhtiSE2fK1kFF4fpkyzHs%3d