Re: record field names vs. -fwarn-unused-binds

[Thomas Miedema]

Through a patch

by Oleg Grenrus (phadej), GHC 8 will have the following new flags:
 -fwarn-unused-top-binds
 -fwarn-unused-local-binds
 -fwarn-unused-pattern-binds

So you'll be able to pick and choose.


On Tue, Nov 3, 2015 at 6:47 PM, Evan Laforge  wrote:

> [ ccing haskell-cafe since while it's a ghc flag, I'll bet most
> compilers have an equivalent ]
>
> I really like -fwarn-unused-binds because it frequently finds bugs
> where I forgot to call something or use some value.  If I put an
> export list on, it can find dead functions I forgot to delete.
> However, there's one case where it frequently gives false positives,
> and that's unused record field names.  The problem is that I sometimes
> use record field names as documentation, but the record itself is
> internal and small, so I'm comfortable using positional pattern
> matching to open it (and in fact that can be safer, since then
> warn-unused-binds will make sure I used all the fields).  But GHC sees
> these as unused functions, so it warns about them.  I can work around
> by putting underscores on field names I haven't used yet, but it's a
> hassle to go edit them when I want to use them.  The warning can be
> useful if it indicates an unused field, but since fields can also be
> extracted via the positional syntax it's not reliable.  The other use
> of the warning for dead code or functions you forgot to use doesn't
> apply to record accessors because they're trivial and compiler
> generated.
>
> So, would it be reasonable to exclude record field accessors from
> -fwarn-unused-binds?  Or is there another way to work around it?  I
> guess GHC doesn't have a "suppress warning" pragma like Java does, but
> even if we did it wouldn't be much better than changing the name, and
> more likely to get stale.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

record field names vs. -fwarn-unused-binds

[Evan Laforge]

[ ccing haskell-cafe since while it's a ghc flag, I'll bet most
compilers have an equivalent ]

I really like -fwarn-unused-binds because it frequently finds bugs
where I forgot to call something or use some value.  If I put an
export list on, it can find dead functions I forgot to delete.
However, there's one case where it frequently gives false positives,
and that's unused record field names.  The problem is that I sometimes
use record field names as documentation, but the record itself is
internal and small, so I'm comfortable using positional pattern
matching to open it (and in fact that can be safer, since then
warn-unused-binds will make sure I used all the fields).  But GHC sees
these as unused functions, so it warns about them.  I can work around
by putting underscores on field names I haven't used yet, but it's a
hassle to go edit them when I want to use them.  The warning can be
useful if it indicates an unused field, but since fields can also be
extracted via the positional syntax it's not reliable.  The other use
of the warning for dead code or functions you forgot to use doesn't
apply to record accessors because they're trivial and compiler
generated.

So, would it be reasonable to exclude record field accessors from
-fwarn-unused-binds?  Or is there another way to work around it?  I
guess GHC doesn't have a "suppress warning" pragma like Java does, but
even if we did it wouldn't be much better than changing the name, and
more likely to get stale.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[Evan Laforge]

A diff is up at https://phabricator.haskell.org/D1427

On Sat, Oct 24, 2015 at 1:14 PM, Evan Laforge  wrote:
> Ok, ticket created.  I'll go see how much I can figure out on my own.
>
> https://ghc.haskell.org/trac/ghc/ticket/11014
>
> WRT the "bound at" bits in "relevant bindings", I have no strong opinion.
> What about omitting them if they are in the same file as the main error?  Or
> maybe they always are?  I'm not totally clear how it chooses which bindings
> are relevant.
>
> On Sat, Oct 24, 2015 at 12:50 PM, Simon Peyton Jones 
> wrote:
>>
>> I’m all for it.   Can advise.  (Make a ticket.)
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Simon
>>
>>
>>
>> From: Glasgow-haskell-users
>> [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Evan Laforge
>> Sent: 24 October 2015 03:48
>> To: GHC users
>> Subject: type error formatting
>>
>>
>>
>> Here's a typical simple type error from GHC:
>>
>>
>>
>> Derive/Call/India/Pakhawaj.hs:142:62:
>> Couldn't match type ‘Text’ with ‘(a1, Syllable)’
>> Expected type: [([(a1, Syllable)], [Sequence Bol])]
>>   Actual type: [([Syllable], [Sequence Bol])]
>> Relevant bindings include
>>   syllables :: [(a1, Syllable)]
>> (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>>   best_match :: [(a1, Syllable)]
>> -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence
>> Bol)]))
>> (bound at Derive/Call/India/Pakhawaj.hs:141:5)
>> In the second argument of ‘mapMaybe’, namely ‘all_bols’
>> In the second argument of ‘($)’, namely
>>   ‘mapMaybe (match_bols syllables) all_bols’
>>
>> I've been having more trouble than usual reading GHC's errors, and I
>> finally spent some time to think about it.  The problem is that this new
>> "relevant bindings include" section gets in between the expected and actual
>> types (I still don't like that wording but I've gotten used to it), which is
>> the most critical part, and the location context, which is second most
>> critical.  Notice the same effect in the previous sentence :)  After I see a
>> type error the next thing I want to see is the where it happened, so I have
>> to skip over the bindings, which can be long and complicated.  Then I
>> usually know what to do, and only look into the bindings if something more
>> complicated is going on, like wonky inference.  So how about reordering the
>> message:
>>
>> Derive/Call/India/Pakhawaj.hs:142:62:
>> Couldn't match type ‘Text’ with ‘(a1, Syllable)’
>> Expected type: [([(a1, Syllable)], [Sequence Bol])]
>>   Actual type: [([Syllable], [Sequence Bol])]
>> In the second argument of ‘mapMaybe’, namely ‘all_bols’
>> In the second argument of ‘($)’, namely
>>   ‘mapMaybe (match_bols syllables) all_bols’
>> Relevant bindings include
>>   syllables :: [(a1, Syllable)]
>> (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>>   best_match :: [(a1, Syllable)]
>> -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence
>> Bol)]))
>> (bound at Derive/Call/India/Pakhawaj.hs:141:5)
>>
>> After this, why not go one step further and set off the various sections
>> visibly to make it easier to scan.  The context section can also be really
>> long if it gets an entire do block or record:
>>
>> Derive/Call/India/Pakhawaj.hs:142:62:
>>   * Couldn't match type ‘Text’ with ‘(a1, Syllable)’
>> Expected type: [([(a1, Syllable)], [Sequence Bol])]
>>   Actual type: [([Syllable], [Sequence Bol])]
>>   * In the second argument of ‘mapMaybe’, namely ‘all_bols’
>> In the second argument of ‘($)’, namely
>>   ‘mapMaybe (match_bols syllables) all_bols’
>>   * Relevant bindings include
>>   syllables :: [(a1, Syllable)]
>> (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>>   best_match :: [(a1, Syllable)]
>> -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence
>> Bol)]))
>> (bound at Derive/Call/India/Pakhawaj.hs:141:5)
>>
>>
>>
>> Or alternately, taking up a bit more vertical space:
>>
>>
>>
>> Derive/Call/India/Pakhawaj.hs:142:62:
>> Couldn't match type ‘Text’ with ‘(a1, Syllable)’
>> Expected type: [([(a1, Syllable)], [Sequence Bol])]
>>   Actual type: [([Syllable], [Sequence Bol])]
>>
>> -
>> In the second argument of ‘mapMaybe’, namely ‘all_bols’
>> In the second argument of ‘($)’, namely
>>   ‘mapMaybe (match_bols syllables) all_bols’
>>
>> -
>> Relevant bindings include
>>
>>   syllables :: [(a1, Syllable)]
>> (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>>   best_match :: [(a1, Syllable)]
>> -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence
>> Bol)]))
>> (bound at Derive/Call/India/Pakhawaj.hs:141:5)
>>
>>
>>
>> Thoughts?  It seems simple enough that I could do myself, but of course
>> not without buy-in.
>
>