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

#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
participants (1)
-
GHC