[GHC] #1171: GHC doesn't respect the imprecise exceptions semantics

[GHC]

#1171: GHC doesn't respect the imprecise exceptions semantics
-------------------------------+--------------------------------------------
  Reporter:  neil              |          Owner:                  
      Type:  bug               |         Status:  new             
  Priority:  low               |      Milestone:  _|_             
 Component:  Compiler          |        Version:  6.6             
Resolution:                    |       Keywords:                  
        Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown      |     Difficulty:  Unknown         
  Testcase:  cg059             |      Blockedby:                  
  Blocking:                    |        Related:                  
-------------------------------+--------------------------------------------

Comment(by simonpj):

 Here are some more notes about this subject, culled from an
 exchange betwen Simon M and Simon PJ.

 Consider this:
 {{{
 f :: Bool -> (Int,Int) -> Int
 f x y = case x of
             True -> error "urk"
             False -> case y of (a,b) -> a+b
 }}}
 Can we pass y unboxed?  Yes, we do so, because we regard
 bottom (the error branch) as hyperstrict in everything.  So we do
 a w/w split thus
 {{{
 f x y = case y of (a,b) ->
           case a of I# a1 ->
           case b of I# b1 ->
           fw x a1 b1
 }}}
 That means, of course, that `(f True (error "a", 3))` would throw `(error
 "a")` not `(error "urk")`.
 The paper doesn't allow this, but I believe that it's crucial for
 strictness analysis to work well.

 However, if the function unconditionally diverges, it seems stupid to
 unbox:
 {{{
 f :: (Int,Int) -> a
 f x = error "urk"
 }}}
 Here it seems fruitless to do the same w/w/ split as I gave
 above, even though the semantics justifies it equally.  So
 pragmatically we do NOT do w/w for a hyper-strict demand.
 Another variant:
 {{{
 f :: (Int,Int) -> a
 f (x,y) = error (show x)

 main = ...(f (3, error "no no"))...
 }}}
 Similar to the previous example, the `(error "no no")` is not even used,
 so it would be very odd indeed to evaluate it before the call to `f`.
 See
 {{{
 Note [Unpacking arguments with product and polymorphic demands]
 }}}
 in `stranal/WwLib`.

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