[GHC] #2831: Floated error expressions get poor strictness, leaving bad arity

[GHC]

#2831: Floated error expressions get poor strictness, leaving bad arity
---------------------------------------+------------------------------------
  Reporter:  simonpj                   |          Owner:                  
      Type:  run-time performance bug  |         Status:  new             
  Priority:  normal                    |      Milestone:                  
 Component:  Compiler                  |        Version:  6.10.1          
  Severity:  normal                    |       Keywords:                  
Difficulty:  Unknown                   |       Testcase:                  
        Os:  Unknown/Multiple          |   Architecture:  Unknown/Multiple
---------------------------------------+------------------------------------
 GHC is careful to ensure that
 {{{
   f = \x.  case x of
                [] -> error "urk"
                (y:ys) -> \z. <blah>
 }}}
 gets arity 2. It does this by giving `error` an infinite arity.  But if
 the error call is floated out by full laziness thus
 {{{
   lvl = error "urk"
   f = \x.  case x of
                [] -> lvl
                (y:ys) -> \z. <blah>
 }}}
 it's a bit less obvious.  But it's ok: the strictness analyser disovers
 that `lvl` diverges.

 Alas, if `f` is marked INLINE, there's a danger that this does not happen
 properly, perhaps because the inlining happens after strictness analysis.
 Or because the error message involves the parameter:
 {{{
   {-# INLINE f #-}
   f = \x. case x of
             [] -> error ("urk" ++ x)
             (y:ys) -> \z. <blah>
 }}}
 I think I've seen this in connection with array indexing (where the error
 case is the index out of bounds error).  I'm recording this ticket so that
 I don't forget about this problem.

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