[GHC] #5557: Code using seq has wrong strictness (too lazy)

[GHC]

#5557: Code using seq has wrong strictness (too lazy)
-------------------------------------------+--------------------------------
    Reporter:  michal.palka                |        Owner:                             
        Type:  bug                         |       Status:  new                        
    Priority:  high                        |    Milestone:  7.4.1                      
   Component:  Compiler                    |      Version:  7.2.1                      
    Keywords:  seq strictness strict lazy  |     Testcase:                             
   Blockedby:                              |   Difficulty:                             
          Os:  Unknown/Multiple            |     Blocking:                             
Architecture:  Unknown/Multiple            |      Failure:  Incorrect result at runtime
-------------------------------------------+--------------------------------

Comment(by simonpj@…):

 commit 6d5dfbf750320dd7bd0fea8e2965935fcedbe15e
 {{{
 Author: Simon Peyton Jones <simonpj at microsoft.com>
 Date:   Fri Oct 21 16:34:21 2011 +0100

     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 |   34 +++++++++++++++++++++++++++++++---
  1 files changed, 31 insertions(+), 3 deletions(-)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5557#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler