#10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:751 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The real culprit here is the eta-reduction of {{{ t = \x -> t x }}} In general `CoreUtils.tryEtaReduce` eta-reduces `\x t x` to `t` if `t` is a head-normal form, definitely not bottom. However, here `t` cheerfully says that its arity is 1, and so the eta-reduction goes ahead. But now its arity isn't 1 any more! And the eta-reduction is unsound, because {{{t `seq` True}}} will behave differently than before. One simple solution would be this: * Never eta-reduce a let right-hand side. See `SimplUtils.mkLam`, which refrains from eta-expansion of let right-hand sides. This a bit drastic because it doesn't eta-reduce the non-recursive {{{ myMap = \f x -> map f x }}} When we eta-reduce we get a trivial binding, so we can substitute, and win all round. So a better strategy would be * Never eta-reduce a let right-hand side of a recursive group. To do this, we'd have to augment `RhsCtxt` (the data constructor of `CoreUnfold.CallCtxt`) with a `RecFlag`. My bet is that this more conservative story would do little harm. More ambitiously, we should look at at recursive group of bindings as a whole. We already have special treatment for eta ''expansion'' for let(rec) rhss; see `SimplUtils.tryEtaExpandRhs`. But it is still one- binding-at-a-time, which isn't as good as it could be; see `Note [Arity analysis]` in `CoreArity`. We could instead do eta expansion and reduction for let(rec) RHSs for a group as a whole. This latter seems like the Right Thing to do. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10181#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler