[GHC] #11451: Inconsistent warnings for unused binders

[GHC]

#11451: Inconsistent warnings for unused binders
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.10.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by ekmett):

 That can be used to work around this particular concern somewhat, though
 the mangled names will show up in haddocks and :t and the like, making
 things a lot noisier. In contrast, the stuff that happens at the value
 level doesn't make it into the documentation.

 I'm much more concerned by the mention that we may want to start applying
 this reasoning to instances, however.

 > Currently GHC does not warn about type variables bound in the instance
 head but unused in the where part. Fixing that might be a good idea [snip]

 There one can argue that those type variables are serving multiple roles.

 Consider that

 {{{
 instance Foo (a,a)
 }}}

 is quite different than

 {{{
 instance a ~ b => Foo (a,b)
 }}}

 The fact that there are multiple type variables is actually providing
 information about what is required to unify with what. The instance head
 interacts with 'itself' in that way. The relationships between the type
 variables that show up in the signature matter, even if they never appear
 in the body itself.

 At the value level patterns are forced to be linear, multiple uses aren't
 a concern, but at least in instance heads non-linear patterns arise rather
 frequently, so that may make it more palatable to not try to shoehorn
 instance heads into this same uniform handling.

 Also, if dealing with the fact that every type family is going to start
 setting off alarm bells is bad, forcing a change on probably 95% of the
 instances out there is likely to cause panic in the streets. ;)

 It'd also show up in mangled form throughout the haddocks, creating an
 uncomfortable tension between seeing the warning and providing pretty
 documentation. That is less of a concern for type instances and class
 associated types, but mostly just because there are a lot fewer of those.

 My primary concern is that it isn't obvious to me that even a single user
 error in the wild will actually be caught by the change, in exchange for
 all of this mangling. I'm concerned that it seems like a lot of make-work
 for users and the end state isn't really any nicer than the one we started
 in, hence my unease above. We make things a little more strict for library
 authors, but make things uglier for users.

 I'd personally be okay with changing all my code around to work with these
 type families and type synonym warnings.

 That said, doing the same with instances seems like it would be a pretty
 radical departure from existing practice, and I think once we start doing
 this to `type`, we'll start eyeballing `data` and `newtype` next, and I
 can see a lot of code and documentation getting uglier with little upside
 and it getting worse the farther down that road we travel.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11451#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler