Enable -Wall by default?

Fumiaki Kinoshita

9 Dec 2020 9 Dec '20

9:06 p.m.

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? [0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3

Attachments:

attachment.html (text/html — 945 bytes)

Show replies by date

David Feuer

9 Dec 9 Dec

9:23 p.m.

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

[0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3 _______________________________________________ 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.

Fumiaki Kinoshita

11:57 p.m.

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 :

...

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

[0] https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3 _______________________________________________ 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.

MarLinn

10 Dec 10 Dec

7:44 p.m.

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.

Álvaro Māthes

9:56 p.m.

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

Viktor Dukhovni

12:16 a.m.

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.

Georgi Lyubenov

2:50 a.m.

For me, the default is -Wall and the "production" version is also turning on -Werror. I'm +1 on this. ======= Georgi

Albert Y. C. Lai

2:46 p.m.

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

Joachim Durchholz

4:49 p.m.

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

Albert Y. C. Lai

6:06 p.m.

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.

David Feuer

10:02 p.m.

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

Joachim Durchholz

11 Dec 11 Dec

12:15 a.m.

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

Fumiaki Kinoshita

18 Dec 18 Dec

12:09 a.m.

Thanks for the feedback. Apparently it's controversial so I decided not to submit the proposal. 2020年12月11日(金) 14:15 Joachim Durchholz :

...

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.

Georgi Lyubenov

5:23 a.m.

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

Ben Franksen

21 Dec 21 Dec

1:25 p.m.

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

Henning Thielemann

6:03 p.m.

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.

David Feuer

6:28 p.m.

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 < lemming@henning-thielemann.de> 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.

Ben Franksen

6:36 p.m.

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

Oleg Grenrus

22 Dec 22 Dec

6:18 a.m.

...

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.

Ben Franksen

2:19 p.m.

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

Tom Ellis

2:31 p.m.

On Tue, Dec 22, 2020 at 08:19:57PM +0100, Ben Franksen wrote:

...

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?

I don't think it even existed when I made the proposal! It seems to have appeared in 8.4 in March 2018. https://hackage.haskell.org/package/base/changelog https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-hist... https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/using-warning... https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/using-warning... Tom

1611

Age (days ago)

1623

Last active (days ago)

List overview

Download

20 comments

12 participants

participants (12)

Albert Y. C. Lai
Ben Franksen
David Feuer
Fumiaki Kinoshita
Georgi Lyubenov
Henning Thielemann
Joachim Durchholz
MarLinn
Oleg Grenrus
Tom Ellis
Viktor Dukhovni
Álvaro Māthes