Skip to content

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.

  • arityType is the main one. It is not directly exported and entered through findRhsArity and exprEtaExpandArity.
  • 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 in myExprIsCheap/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 of cheapArityType:
      exprIsDeadEnd e = case cheapArityType e of
                           AT lams div -> null lams && isDeadEndDiv div
    If it is just a specialisation, why can't we share code, then?! And then the comment mentions exprIsBotStrictness_maybe which appears to call cheapArityType directly. Another opportunity to share the same generalised function, I suppose.
  • Finally, we have exprArity, which claims to be even more approximate than cheapArityType (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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information