[Discussion] Integrating Hlint in the repo: why, what, where

This ticket opens the discussion on Hlint integration in the ghc repository. This is a tricky subject, so let me put some foundations to the discussion:

Why

• This is not about blindly integrating Hlint in the whole codebase
• This is not about turning on all the lints by default
• This is not about ruling out the usage of other tools in the future (like stan)
• This is about determining, as a community of contributors and professionals, which are the lints that may benefit us the most
• This is about starting a progressive integration of the linting process

What

From a personal experience, here are some of the hints I find useful (and use in my professional life):

• Use DerivingStrategies
• The generalise group ((++) -> (<>), map -> fmap, etc)
• Replacing sequence by sequenceA, to ease the Monad restriction
• Replacing return by pure
• Replacing nub (which is Ο(n^2)) with ordNub
• Replacing the usage of some notoriously unsafe-yet-popular functions like head, tail, fromJust with safe equivalents (using NonEmpty, using functions that return a Maybe a, etc)
• Turning off the Eta reduce hint

This is of course up for discussion, I do not claim that my experience is objectively better than another. That being said, Hlint is quite a powerful tool in its space, and will definitely help setting coding standards that might get past a reviewer's attention.

Where

I suggest that Hlint should be enabled first in the projects of the libraries/ directory, on a case-by-case basis. The reason is simple: Each of those libraries may (and will) generate a copious amount of hint warnings, so the work will be easier to get done if we adopt a granular integration (and it can be parallelised).

The older parts of GHC may benefit from more reflection on which hints should be enabled. As said before, this is a tricky subject.

Thank you for reading.