Be even more careful about eta expansion when bottom is involved
authorSimon Peyton Jones <simonpj@microsoft.com>
Fri, 21 Oct 2011 15:34:21 +0000 (16:34 +0100)
committerSimon Peyton Jones <simonpj@microsoft.com>
Fri, 21 Oct 2011 15:34:21 +0000 (16:34 +0100)
commit6d5dfbf750320dd7bd0fea8e2965935fcedbe15e
treeef227789941e0737ef5b43ae1ab0078dc33d2c4d
parentfb83cd0239e6d50b0ef0ad5cd9b641f0b4df032c
Be even more careful about eta expansion when bottom is involved

See Note [Dealing with bottom], reproduced below.  Fixes Trac #5557.

3.  Note [Dealing with bottom]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Consider
f = \x -> error "foo"
Here, arity 1 is fine.  But if it is
f = \x -> case x of
True  -> error "foo"
False -> \y -> x+y
then we want to get arity 2.  Technically, this isn't quite right, because
(f True) `seq` 1
should diverge, but it'll converge if we eta-expand f.  Nevertheless, we
do so; it improves some programs significantly, and increasing convergence
isn't a bad thing.  Hence the ABot/ATop in ArityType.

However, this really isn't always the Right Thing, and we have several
tickets reporting unexpected bahaviour resulting from this
transformation.  So we try to limit it as much as possible:

 * Do NOT move a lambda outside a known-bottom case expression
      case undefined of { (a,b) -> \y -> e }
   This showed up in Trac #5557

 * Do NOT move a lambda outside a case if all the branches of
   the case are known to return bottom.
      case x of { (a,b) -> \y -> error "urk" }
   This case is less important, but the idea is that if the fn is
   going to diverge eventually anyway then getting the best arity
   isn't an issue, so we might as well play safe

Of course both these are readily defeated by disguising the bottoms.
compiler/coreSyn/CoreArity.lhs