3 release policy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

3 release policy

Jonathon Delgado
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.
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Richard Eisenberg-2
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Edward Kmett-2
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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Vincent Hanquez


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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Mark Lentczner-2
In reply to this post by Richard Eisenberg-2
On Tue, Oct 20, 2015 at 5:02 PM, Richard Eisenberg <[hidden email]> wrote:
I wonder if part of the problem is that Haskell is optimized for programmers who prize beauty and cleanliness. Warnings are ugly!

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 is that as code bases get bigger and older, and gain engineers, it becomes impossible to know which warnings are "oh yeah, just ignore that" and which are "oh that's new, maybe we should look at it."

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Evan Laforge
On Tue, Oct 20, 2015 at 5:48 PM, Mark Lentczner
<[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: 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:[hidden email]] 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 <[hidden email]>
|  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
|  [hidden email]
|  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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Michael Snoyman
In reply to this post by Vincent Hanquez


On Wed, Oct 21, 2015 at 12:23 AM, Vincent Hanquez <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


+1

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Henning Thielemann
In reply to this post by Jonathon Delgado

On Tue, 20 Oct 2015, 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.

If you accept warnings in your code you always have to check which
warnings are relevant and which ones you want to react on. Checking for no
warnings is much simpler.

Actually, I don't pay attention to GHC-7.10 warnings anymore because there
are so many irrelevant duplicate import warnings. I am not using GHC-7.10
seriously, it has this intermediate flavour (also because of the type
family problem I mentioned earlier). Thus the 3 release policy for me is
already only a "2 usable releases policy".

Btw. I use every LTS version of Ubuntu full 4 years. 2 years is still too
frequent change for me.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Petr Pudlák
In reply to this post by Evan Laforge

+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 <[hidden email]> napsal:
On Tue, Oct 20, 2015 at 5:48 PM, Mark Lentczner
<[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

evan@evan-borden.com

> +1 to be able to suppress warnings locally.

Isn't this already possible with the OPTIONS_GHC pragma?

{-# OPTIONS_GHC -fnowarn-____ #-}


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Adam Bergmark-2
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, [hidden email] <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Jonathon Delgado
.NET has a very flexible system for suppressing code analysis warnings, it may be informative for formulating a GHC solution.

https://msdn.microsoft.com/en-us/library/ms244717.aspx
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Thomas Miedema
In reply to this post by Adam Bergmark-2

On Wed, Oct 21, 2015 at 2:13 PM, Adam Bergmark <[hidden email]> 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").


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

John Wiegley-2
In reply to this post by Simon Peyton Jones
>>>>> Simon Peyton Jones <[hidden email]> 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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

M Farkas-Dyck
On 21/10/2015, John Wiegley <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

Dmitry Olshansky
In reply to this post by Jonathon Delgado
Personally as user of libraries I have no problem with warnings. Because
- I can't improve it
- I got it only once when install library 

I just care about warnings in my projects and that is not so hard.

So I want to say that it is not a big deal. Perhaps warning's levels are good but simplicity is more important for me.

Dmitry

2015-10-20 22:55 GMT+03:00 Jeremy <[hidden email]>:
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 3 release policy

David Thomas
In reply to this post by M Farkas-Dyck
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 <[hidden email]> wrote:

> On 21/10/2015, John Wiegley <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

warnings per organisation (Was: 3 release policy)

Henning Thielemann
In reply to this post by Simon Peyton Jones

On Wed, 21 Oct 2015, Simon Peyton Jones wrote:

> 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 think it must be specified in the Cabal file of a project, such that
other programmers get the same list of warnings as the main developer. And
that's actually how it currently works: If I want to see warnings I must
add GHC-Options: -Wall to a Cabal file, and sometimes I add more warning
switches if I recall them.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries