I'm not sure HLint is aware of RankNTypes
at all, perhaps not.
Indeed eta reduction is often impossible with that extension on. GHC can't just unify a->a
and (forall b.b -> b) -> (forall c.c -> c)
, otherwise it would completely mess up its type inference capability for Rank1-code1. OTOH, it's not a problem to unify (forall b.b -> b)
with the a
argument; the result is confimed to be (forall b.b -> b)
which matches with (forall c.c -> c)
.
1Consider map id [(+1), (*2)]
. If id
were allowed to have the type you're dealing with, the compiler could end up producing different instance choice for the polymorphic Num
functions, which certainly shouldn't be possible. Or should it? I'm not sure, thinking about it...
At any rate, I'm pretty sure its proven that with RankNTypes, full type inference is not possible, so to get it at least in the Rank1 subset GHC must usually default to this as a less-than-possible polymorphic choice.