Enable -Wall by default?

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

Enable -Wall by default?

Fumiaki Kinoshita
I mean literally. An article [0] reminded me of the fact that I enable -Wall in 99% of time -- and most packages I use have it enabled too.
It's well known that -Wall doesn't enable all warnings, but a subset of warnings that

* are well accepted by the community
* rarely produce false positives

Well, they look like good reasons to enable the warnings by default. Same goes for -Wcompat, except that it is not as popular as -Wall. Seeing potential problems when compiling code is far less of a pain than leaving breakages unnoticed.

Am I missing some obvious reason not to do this?


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

David Feuer
Yeah, I think you're missing something. -Wall is great for checking code that's supposed to be "production ready", but it makes some pretty annoying noise when you're deep in development. Probably the most annoying in that context are unused binding warnings (yeah, I'm not using it yet because I'm still writing it and/or other helpers), unused variable warnings (yeah, that'll be used in some case I still need to write), and unused imports (yeah, I've temporarily commented out the code that uses Foo, and I'm pretty sure I'll be needing Bar before I'm done). In that setting, I'm much more likely to want -Wincomplete-patterns (what do I still need to write) and maybe -Wname-shadowing (so I won't have to go back and change a bunch of names later) than full -Wall.

On Wed, Dec 9, 2020, 9:06 PM Fumiaki Kinoshita <[hidden email]> wrote:
I mean literally. An article [0] reminded me of the fact that I enable -Wall in 99% of time -- and most packages I use have it enabled too.
It's well known that -Wall doesn't enable all warnings, but a subset of warnings that

* are well accepted by the community
* rarely produce false positives

Well, they look like good reasons to enable the warnings by default. Same goes for -Wcompat, except that it is not as popular as -Wall. Seeing potential problems when compiling code is far less of a pain than leaving breakages unnoticed.

Am I missing some obvious reason not to do this?

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Fumiaki Kinoshita
I've been pretty comfortable with using -Wall from the beginning, but I see the point. I think -Wall is still a good reminder to fix unused bindings, imports etc.
How about having a flag that disables those warnings while in early development? That would serve as a more explicit WIP marker.

2020年12月10日(木) 11:23 David Feuer <[hidden email]>:
Yeah, I think you're missing something. -Wall is great for checking code that's supposed to be "production ready", but it makes some pretty annoying noise when you're deep in development. Probably the most annoying in that context are unused binding warnings (yeah, I'm not using it yet because I'm still writing it and/or other helpers), unused variable warnings (yeah, that'll be used in some case I still need to write), and unused imports (yeah, I've temporarily commented out the code that uses Foo, and I'm pretty sure I'll be needing Bar before I'm done). In that setting, I'm much more likely to want -Wincomplete-patterns (what do I still need to write) and maybe -Wname-shadowing (so I won't have to go back and change a bunch of names later) than full -Wall.

On Wed, Dec 9, 2020, 9:06 PM Fumiaki Kinoshita <[hidden email]> wrote:
I mean literally. An article [0] reminded me of the fact that I enable -Wall in 99% of time -- and most packages I use have it enabled too.
It's well known that -Wall doesn't enable all warnings, but a subset of warnings that

* are well accepted by the community
* rarely produce false positives

Well, they look like good reasons to enable the warnings by default. Same goes for -Wcompat, except that it is not as popular as -Wall. Seeing potential problems when compiling code is far less of a pain than leaving breakages unnoticed.

Am I missing some obvious reason not to do this?

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Viktor Dukhovni
In reply to this post by David Feuer
On Wed, Dec 09, 2020 at 09:23:34PM -0500, David Feuer wrote:

> Yeah, I think you're missing something. -Wall is great for checking code
> that's supposed to be "production ready", but it makes some pretty annoying
> noise when you're deep in development. Probably the most annoying in that
> context are unused binding warnings (yeah, I'm not using it yet because I'm
> still writing it and/or other helpers), unused variable warnings (yeah,
> that'll be used in some case I still need to write), and unused imports
> (yeah, I've temporarily commented out the code that uses Foo, and I'm
> pretty sure I'll be needing Bar before I'm done). In that setting, I'm much
> more likely to want -Wincomplete-patterns (what do I still need to write)
> and maybe -Wname-shadowing (so I won't have to go back and change a bunch
> of names later) than full -Wall.

But since the proposal is about *defaults*, and a hypothetical
*default* "-Wall" can be explicitly disabled:

    $ ghci -Wall
    λ> foo :: Bool -> Int ; foo True = 1

    <interactive>:1:22: warning: [-Wincomplete-patterns]
        Pattern match(es) are non-exhaustive
        In an equation for ‘foo’: Patterns not matched: False
    λ>
    Leaving GHCi.

    ---

    $ ghci -Wall -Wno-all
    λ> foo :: Bool -> Int ; foo True = 1
    λ>
    Leaving GHCi.

the objections you raised don't necessarily rule the proposed default,
one would just need choose to use "-Wno-all" initially, and then later
turn it off.  

A more serious compatibility break would perhaps happen when one
specifies "-Werror", perhaps in combination with specific warnings to
enforce:

    $ ghci -Wall -Werror -Wno-all
    λ> 1 + 2
    3
    λ> foo :: Bool -> Int ; foo True = 1
    λ>
    Leaving GHCi.

    ---

    $ ghci -Wall -Werror
    λ> foo :: Bool -> Int ; foo True = 1

    <interactive>:1:22: error: [-Wincomplete-patterns, -Werror=incomplete-patterns]
        Pattern match(es) are non-exhaustive
        In an equation for ‘foo’: Patterns not matched: False
    λ> 1 + 2

    <interactive>:2:1: error: [-Wtype-defaults, -Werror=type-defaults]
        • Defaulting the following constraints to type ‘Integer’
            (Show a0) arising from a use of ‘print’ at <interactive>:2:1-5
            (Num a0) arising from a use of ‘it’ at <interactive>:2:1-5
        • In a stmt of an interactive GHCi command: print it
    λ>
    Leaving GHCi.

Here, adding an implicit "-Wall" stops code from compiling.  So
backwards-compatible behaviour might require "-Wall" to be explicit when
"-Werror" is specified.

Since my examples are using "ghci", I should note that for me, in
"ghci", I typically want no warnings, and "-Wall" would be a bit
of a nuisance.  But I can always alias (bash):
   
    ghci() { command ghci -v0 -Wno-all "$@"; }

And then no longer see the mostly pedantic "defaulting" warnings, or
whatever else gets in the way of quickly syntax-checking or evaluating
an expression.

--
    Viktor.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Georgi Lyubenov
For me, the default is -Wall and the "production" version is also turning on -Werror.

I'm +1 on this.

=======
Georgi

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Albert Y. C. Lai
-1 from me.  I vote for the status quo.

0. I believe that it really comes down to a vote (as opposed to settling
by technical merit).  My work habit (which stems from my personality) is
going to be the opposite of many people's, and vice versa.  Every
"technical merit" cited on this issue is conditional on accepting a
certain personality.  So yes it has to come down to a vote.  I'm OK if I
happen to be in the minority.

1. -Wall warnings have almost zero correletion with my mistakes.  (See?
my personality dictates what mistakes I make. YMMV.)

An example is unused binds.  My unused binds are intentional, thank you
very much.  I make unused binds because it's future-proof---perhaps I
will actually use it in the next version?  Editing from

(p, _q) = f x

to

(p, q) = f x

produces noise in diffs and commits, no?  Some of you are against noisy
diffs and commits, no?  Then embrace unused binds!

2. In fact, I go so far as adding -fdefer-type-errors during the first
99% of a development cycle.  Why?  Because ghci is so much more
informative when :load succeeds.  Tab completion works.  :type works.
Asking for where a local variable is defined works.  Asking for the type
of an arbitrary subexpression works.  (I use those features via emacs
haskell-mode or dante, of course.)  Would be a pity to throw that all
away just for unfinished code.  Hell, to finish the unfinished code, I
need those ghci features.  90% of the people who think they need a
Haskell IDE, they just need this, -fdefer-type-errors and a low-tech
editor plugin that actually knows what ghci offers.

-fdefer-type-errors still gives me compile-time warnings for what should
be static errors.  I am not losing any information.  Clearly, I don't
consider my job done until all-clear.  Just let me do my job.


On 2020-12-10 2:50 a.m., Georgi Lyubenov wrote:

> For me, the default is -Wall and the "production" version is also
> turning on -Werror.
>
> I'm +1 on this.
>
> =======
> Georgi
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Joachim Durchholz
I generally agree that a lot is subjective, but I believe this one is not:

Am 10.12.20 um 20:46 schrieb Albert Y. C. Lai:

> I make unused binds because it's future-proof---perhaps I
> will actually use it in the next version?  Editing from
>
> (p, _q) = f x
>
> to
>
> (p, q) = f x
>
> produces noise in diffs and commits, no?

No, that's not noise, it's a reminder that _q is now being used.
Sure, there will also be other changes in the function's body. Still, a
single-change noise isn't much concern.

Well okay. If your diff tool does only by-line diffs and not by-word or
by-character diffs, then yeah it's annoying.
This used to be a serious problem a view years ago. Not anymore today
I'd say, word diffs are pretty commonplace nowadays.

> Some of you are against noisy
> diffs and commits, no?  Then embrace unused binds!

Noise in the always-the-same place isn't much of a hassle actually.
At some point I even started to notice the *absence* of some noise and
got alerted to a mistake.

YMMV :-)

> 2. In fact, I go so far as adding -fdefer-type-errors during the first
> 99% of a development cycle.  Why?  Because ghci is so much more
> informative when :load succeeds.

Will -Wall prevent :load?
If not, this particular argument is beside the point.

Just my 2 cents.

Regards,
Jo
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Albert Y. C. Lai
On 2020-12-10 4:49 p.m., Joachim Durchholz wrote:
> Will -Wall prevent :load?
> If not, this particular argument is beside the point.

-Wall will hide the few warnings I need in the haystack of a lot of
warnings I don't need.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

MarLinn
In reply to this post by Fumiaki Kinoshita

While I do get many of the points mentioned in this thread, I don't see a reason to change a default.

Because

    A) you can set your own default with magic .ghci files, and

    B) there's so much more to a well-set-up development $HOME than just a -Wall and a big (editor) window.

In fact quite a few of the different problems mentioned in this thread can be solved with a bit of tinkering.
Here is my setup as an example:

My main companion .ghci file lives with me in my $HOME. When I take it for walkies it runs a few others (~/.ghc/macros) to set prompts and default editor, to import lambdabot and hoogle, and to setup a few other niceties, but it also contains these two key lines:

	:set -Wall -fdefer-typed-holes -fwarn-tabs -fwarn-incomplete-uni-patterns -fwarn-incomplete-record-updates -fwarn-identities -fwarn-hi-shadowing -Wredundant-constraints
	:seti -XTemplateHaskell -XQuasiQuotes -XUnicodeSyntax -XTupleSections

There's that -Wall. I have forgotten what half of the others mean, but they sort of accumulated over time.

Now you might say those are too many warnings. Yes. I want all of these warnings when I'm finalizing a module, but not while I'm still working on a new one.
And what's with those extensions?

Well, I also have a default set of language extensions I almost always want, both in ghci and my files. And I was tired of re-typing the same old imports, too. So I made several templates. A tiny bit of Haskell scripting magic turns them into a fresh new module whenever I want to start a new one.

Here's one of those templates:


	#! /usr/bin/env runghc
	{-# OPTIONS_GHC -fno-warn-unused-imports #-}
	{-# LANGUAGE
	    UnicodeSyntax
	  , OverloadedStrings
	  , TupleSections
	  , RecordWildCards
	  , MultiWayIf
	  , LambdaCase
	  #-}
	
	module §name§
	  where
	
	import           Control.Applicative
	import           Control.Arrow
	import           Control.Monad
	import           Data.Monoid
	import           Data.Either
	import           Data.Function
	import           Data.List
	import           Data.Maybe
	import           Data.Foldable
	import           Data.Traversable
	import           Data.Map.Strict         ( Map )
	import qualified Data.Map.Strict  as Map
	import           Data.Set                ( Set )
	import qualified Data.Set         as Set

In fact when I say "Haskell scripting magic", I mean "Haskell scripting magic that's got its own ghci command, defined in the .ghci file".

So when I want a new module, I simply say

	:create Example
	:l Example.hs
	:e

And off I go.

When I'm done with the module I remove that one -fno-warn and start cleaning up.
I said those where too many warnings for me, not way too many warnings, right?

Is this a set of warnings or extension everyone wants? Absolutely not. Is it time to prune this to adapt to changed GHC defaults? Probably. Should I rework this some day to use an actual templating library like ginger instead of my own quickly-cobbled-together mess? Maybe. And it should probably also adapt to the project structure by looking into .cabal files. But for now, it works great for my use cases and coding style.

Don't get me wrong, changing the default might still be a good idea. But I also don't see a reason to be bothered by it.

Cheers.



_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Alfred Matthews
Peanut gallery:

Agreed strongly support non-change and, thank you everyone for this incredibly useful discussion.

Given that, I think I can still briefly extend the initial question without changing it by asking,

What actually happens in simplest clear terms, when one fidgets a compiler flag?

Thank you. Hoping not to re-unlurk.

Btw each off-list is me just to clarify.

On Thu, Dec 10, 2020, 7:46 PM MarLinn <[hidden email]> wrote:

While I do get many of the points mentioned in this thread, I don't see a reason to change a default.

Because

    A) you can set your own default with magic .ghci files, and

    B) there's so much more to a well-set-up development $HOME than just a -Wall and a big (editor) window.

In fact quite a few of the different problems mentioned in this thread can be solved with a bit of tinkering.
Here is my setup as an example:

My main companion .ghci file lives with me in my $HOME. When I take it for walkies it runs a few others (~/.ghc/macros) to set prompts and default editor, to import lambdabot and hoogle, and to setup a few other niceties, but it also contains these two key lines:

	:set -Wall -fdefer-typed-holes -fwarn-tabs -fwarn-incomplete-uni-patterns -fwarn-incomplete-record-updates -fwarn-identities -fwarn-hi-shadowing -Wredundant-constraints
	:seti -XTemplateHaskell -XQuasiQuotes -XUnicodeSyntax -XTupleSections

There's that -Wall. I have forgotten what half of the others mean, but they sort of accumulated over time.

Now you might say those are too many warnings. Yes. I want all of these warnings when I'm finalizing a module, but not while I'm still working on a new one.
And what's with those extensions?

Well, I also have a default set of language extensions I almost always want, both in ghci and my files. And I was tired of re-typing the same old imports, too. So I made several templates. A tiny bit of Haskell scripting magic turns them into a fresh new module whenever I want to start a new one.

Here's one of those templates:


	#! /usr/bin/env runghc
	{-# OPTIONS_GHC -fno-warn-unused-imports #-}
	{-# LANGUAGE
	    UnicodeSyntax
	  , OverloadedStrings
	  , TupleSections
	  , RecordWildCards
	  , MultiWayIf
	  , LambdaCase
	  #-}
	
	module §name§
	  where
	
	import           Control.Applicative
	import           Control.Arrow
	import           Control.Monad
	import           Data.Monoid
	import           Data.Either
	import           Data.Function
	import           Data.List
	import           Data.Maybe
	import           Data.Foldable
	import           Data.Traversable
	import           Data.Map.Strict         ( Map )
	import qualified Data.Map.Strict  as Map
	import           Data.Set                ( Set )
	import qualified Data.Set         as Set

In fact when I say "Haskell scripting magic", I mean "Haskell scripting magic that's got its own ghci command, defined in the .ghci file".

So when I want a new module, I simply say

	:create Example
	:l Example.hs
	:e

And off I go.

When I'm done with the module I remove that one -fno-warn and start cleaning up.
I said those where too many warnings for me, not way too many warnings, right?

Is this a set of warnings or extension everyone wants? Absolutely not. Is it time to prune this to adapt to changed GHC defaults? Probably. Should I rework this some day to use an actual templating library like ginger instead of my own quickly-cobbled-together mess? Maybe. And it should probably also adapt to the project structure by looking into .cabal files. But for now, it works great for my use cases and coding style.

Don't get me wrong, changing the default might still be a good idea. But I also don't see a reason to be bothered by it.

Cheers.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

David Feuer
In reply to this post by Albert Y. C. Lai
Yes, this exactly. Different people have different opinions about which warnings they want in the midst of hacking, but many of us, at least, don't want the potential firehose of -Wall. For one thing, temporarily commenting out even a single function can potentially throw up dozens of warnings for unused bindings and unused constructors.

On Thu, Dec 10, 2020, 6:07 PM Albert Y. C. Lai <[hidden email]> wrote:
On 2020-12-10 4:49 p.m., Joachim Durchholz wrote:
> Will -Wall prevent :load?
> If not, this particular argument is beside the point.

-Wall will hide the few warnings I need in the haystack of a lot of
warnings I don't need.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Joachim Durchholz
In reply to this post by Albert Y. C. Lai
Am 11.12.20 um 00:06 schrieb Albert Y. C. Lai:
> On 2020-12-10 4:49 p.m., Joachim Durchholz wrote:
>> Will -Wall prevent :load?
>> If not, this particular argument is beside the point.
>
> -Wall will hide the few warnings I need in the haystack of a lot of
> warnings I don't need.

You said

 > Because ghci is so much more informative when :load succeeds.

which struck a cognitive dissonance in me, so my question still is: Will
a warning from -Wall prevent :load from succeeding?

Regards,
Jo
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Fumiaki Kinoshita
Thanks for the feedback. Apparently it's controversial so I decided not to submit the proposal.

2020年12月11日(金) 14:15 Joachim Durchholz <[hidden email]>:
Am 11.12.20 um 00:06 schrieb Albert Y. C. Lai:
> On 2020-12-10 4:49 p.m., Joachim Durchholz wrote:
>> Will -Wall prevent :load?
>> If not, this particular argument is beside the point.
>
> -Wall will hide the few warnings I need in the haystack of a lot of
> warnings I don't need.

You said

 > Because ghci is so much more informative when :load succeeds.

which struck a cognitive dissonance in me, so my question still is: Will
a warning from -Wall prevent :load from succeeding?

Regards,
Jo
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Georgi Lyubenov
How about at least encouraging newcomers to try out -Wall in some visible place? Especially for newcomers to programming in general who are not used to turning on warnings. In my teaching experience it easily exposes "code smells" in students' code, but someone learning on their own/learning from a teacher who doesn't turn on -Wall would entirely miss this.

=======
Georgi

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Ben Franksen
In reply to this post by Albert Y. C. Lai
-1 for almost the same reasons as given below.

Am 10.12.20 um 20:46 schrieb Albert Y. C. Lai:

> -1 from me.  I vote for the status quo.
>
> 0. I believe that it really comes down to a vote (as opposed to settling
> by technical merit).  My work habit (which stems from my personality) is
> going to be the opposite of many people's, and vice versa.  Every
> "technical merit" cited on this issue is conditional on accepting a
> certain personality.  So yes it has to come down to a vote.  I'm OK if I
> happen to be in the minority.
>
> 1. -Wall warnings have almost zero correletion with my mistakes.  (See?
> my personality dictates what mistakes I make. YMMV.)
>
> An example is unused binds.  My unused binds are intentional, thank you
> very much.  I make unused binds because it's future-proof---perhaps I
> will actually use it in the next version?  Editing from
>
> (p, _q) = f x
>
> to
>
> (p, q) = f x
>
> produces noise in diffs and commits, no?  Some of you are against noisy
> diffs and commits, no?  Then embrace unused binds!
>
> 2. In fact, I go so far as adding -fdefer-type-errors during the first
> 99% of a development cycle.  Why?  Because ghci is so much more
> informative when :load succeeds.  Tab completion works.  :type works.
> Asking for where a local variable is defined works.  Asking for the type
> of an arbitrary subexpression works.  (I use those features via emacs
> haskell-mode or dante, of course.)  Would be a pity to throw that all
> away just for unfinished code.  Hell, to finish the unfinished code, I
> need those ghci features.  90% of the people who think they need a
> Haskell IDE, they just need this, -fdefer-type-errors and a low-tech
> editor plugin that actually knows what ghci offers.
>
> -fdefer-type-errors still gives me compile-time warnings for what should
> be static errors.  I am not losing any information.  Clearly, I don't
> consider my job done until all-clear.  Just let me do my job.
>
>
> On 2020-12-10 2:50 a.m., Georgi Lyubenov wrote:
>> For me, the default is -Wall and the "production" version is also
>> turning on -Werror.
>>
>> I'm +1 on this.
>>
>> =======
>> Georgi
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Henning Thielemann
In reply to this post by Fumiaki Kinoshita

On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:

> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3

He's pretty right about pattern matching and -Wall and
-Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the
two latter ones are not part of -Wall. But this is not your proposal.

I have always -Wall on, especially during early development. I can ignore
warnings. But I will always remove the cause for warnings before making a
commit. Warnings remind me on the unfinished bits. Thus also warnings
about unused imports, unused parameters, unused functions are very
important for me.

I would even like to see some warnings before or along type errors.
Currently warnings are shown only after the type errors are resolved.
However, sometimes I get very complicated type errors but actually the
warning "variable x unused" (and thus type inference could not take place)
would be much more helpful.

I have also taught programming to students. They often like to first run
and test their programs and then resolve warnings somewhen in the future
(or not at all). They are surprised why their programs don't work, whereas
the warnings would directly point them to the problems. But -Wall is
disabled by default. And thus making code warning free looks like an
optional extra.

On the other hand I do not know how GHC with -Wall as default affects the
tons of packages that are already released.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

David Feuer
I think the git pull request cycle provides a great deadline for warnings. Well-run projects typically expect code to be -Wall clean before being merged. That sort of discipline is good for personal projects too—everything should be clean before merging a feature branch to the main one.

On Mon, Dec 21, 2020, 6:04 PM Henning Thielemann <[hidden email]> wrote:

On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:

> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3

He's pretty right about pattern matching and -Wall and
-Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the
two latter ones are not part of -Wall. But this is not your proposal.

I have always -Wall on, especially during early development. I can ignore
warnings. But I will always remove the cause for warnings before making a
commit. Warnings remind me on the unfinished bits. Thus also warnings
about unused imports, unused parameters, unused functions are very
important for me.

I would even like to see some warnings before or along type errors.
Currently warnings are shown only after the type errors are resolved.
However, sometimes I get very complicated type errors but actually the
warning "variable x unused" (and thus type inference could not take place)
would be much more helpful.

I have also taught programming to students. They often like to first run
and test their programs and then resolve warnings somewhen in the future
(or not at all). They are surprised why their programs don't work, whereas
the warnings would directly point them to the problems. But -Wall is
disabled by default. And thus making code warning free looks like an
optional extra.

On the other hand I do not know how GHC with -Wall as default affects the
tons of packages that are already released.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Ben Franksen
In reply to this post by Henning Thielemann
Am 22.12.20 um 00:03 schrieb Henning Thielemann:
> On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:
>
>> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
>
> He's pretty right about pattern matching and -Wall and
> -Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the
> two latter ones are not part of -Wall. But this is not your proposal.

Yes, this should definitely be fixed.

> I have always -Wall on, especially during early development. I can
> ignore warnings. But I will always remove the cause for warnings before
> making a commit. Warnings remind me on the unfinished bits. Thus also
> warnings about unused imports, unused parameters, unused functions are
> very important for me.

A very good point, I have run into that problem a lot lately.

Still, this is also not the OP's proposal.

Cheers
Ben

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Oleg Grenrus
> Yes, this should definitely be fixed.

It is

https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4614

Though not -Wpartial-fields (definition site), but
-Wincomplete-record-updates (use site).

- Oleg

On 22.12.2020 1.36, Ben Franksen wrote:

> Am 22.12.20 um 00:03 schrieb Henning Thielemann:
>> On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:
>>
>>> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
>> He's pretty right about pattern matching and -Wall and
>> -Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the
>> two latter ones are not part of -Wall. But this is not your proposal.
> Yes, this should definitely be fixed.
>
>> I have always -Wall on, especially during early development. I can
>> ignore warnings. But I will always remove the cause for warnings before
>> making a commit. Warnings remind me on the unfinished bits. Thus also
>> warnings about unused imports, unused parameters, unused functions are
>> very important for me.
> A very good point, I have run into that problem a lot lately.
>
> Still, this is also not the OP's proposal.
>
> Cheers
> Ben
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Enable -Wall by default?

Ben Franksen
Am 22.12.20 um 12:18 schrieb Oleg Grenrus:

> On 22.12.2020 1.36, Ben Franksen wrote:
>> Am 22.12.20 um 00:03 schrieb Henning Thielemann:
>>> On Thu, 10 Dec 2020, Fumiaki Kinoshita wrote:
>>>
>>>> [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3
>>> He's pretty right about pattern matching and -Wall and
>>> -Wincomplete-uni-patterns and -Wpartial-fields. It's surprising that the
>>> two latter ones are not part of -Wall. But this is not your proposal.
>> Yes, this should definitely be fixed.
>
> It is
>
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4614

Nice!

> Though not -Wpartial-fields (definition site), but
> -Wincomplete-record-updates (use site).

Is there a specific reason or is it just that it wasn't included in the
proposal?

Cheers
Ben

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
12