Currently GHC does not warn about type variables bound in the instance
#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. 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