
#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):
What I'm missing is this: why would it not be more perspicuous to say
{{{#!hs Category * (Indexed _) }}} So that in 3-4 years when I can stop supporting older compilers, I can finally lose the signaling of intent that comes from the conventions that we follow elsewhere of `f` and `m` and `a`? There is a lot of information packed in those conventions. Nobody reading the documentation cares whether the instance uses the argument or not, but this warning would force everyone to put that front and center in the documentation users see and seems to clutter about 70% of the variables in instances out there with a perl-like `_` sigil. I like having names for things rather than Miranda's `*`, `**`, `***`. That said, one of the biggest sources of teasing from the outside world about haskell is how short our type variable names tend to be, getting rid of them entirely like this ''is'' one way to avoid the argument. ;)
If it is, why do you not object to the warning you get (for unused y) when you write this?
{{{#!hs f x y = x }}} Nothing we do at the value level is reflected in the documentation; everything we do at the type level is reflected in the documentation. The fact that the value-level unused binding warning is on or not is invisible to the user of the library. Whether I turn on the warning about unused bindings at the value level or not the user never sees this fact. It remains entirely internal to the source file as a local concern.
That is, do you see class instances and type-function instances the same?
Going from the current state where ''can't'' use `_` in that position at all, to a new state where you ''must'' use `_` or `_a` in a place that affects generated documentation and affects the vast majority of instances that have ever been written seems like a big jump, when the existing style has been in use for 20+ years. This seems to indicate to me that doing this to instances is quite a big deal and the amount of work for the user community boggles my mind. As for type instances, this then hoists you on the dilemma of copying the value level warning style or matching the behavior of instances. The resolution you seem to be reaching for is to change the behavior of instances to match, and it would cleanly resolve the dilemma, but at a rather great cost. In many ways the same "it shows up in the documentation" argument applies to the `type instance` case as well, now that haddock actually shows type families, but there is a lot less code affected. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11451#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler