Arity: Investigate if we can consolidate some of the 4 arity analysis functions
While browsing through GHC.Core.Opt.Arity wondering what a good place for a printf debugging statement might be, I realised that we have at least 4 different arity analyses. 4! To me, that's at least 3 too many.
-
arityTypeis the main one. It is not directly exported and entered throughfindRhsArityandexprEtaExpandArity. - Next we have
cheapArityType, which claims to be a bit faster because it doesn't look through let or case. I really dislike the name because of the overloaded use of "cheap", which we also use inmyExprIsCheap/exprCost. But here it refers to the fact that the analysis itself is fast. Urgh. - Then there's
exprIsDeadEnv, which claims to be a specialisation ofcheapArityType:If it is just a specialisation, why can't we share code, then?! And then the comment mentionsexprIsDeadEnd e = case cheapArityType e of AT lams div -> null lams && isDeadEndDiv divexprIsBotStrictness_maybewhich appears to callcheapArityTypedirectly. Another opportunity to share the same generalised function, I suppose. - Finally, we have
exprArity, which claims to be even more approximate thancheapArityType(which it probably is).
I'd much rather have a single, generalised arityType function that can be inlined and specialised to the 4 different modes necessary.