[GHC] #5129: "evaluate" optimized away

[GHC]

#5129: "evaluate" optimized away
---------------------------------+------------------------------------------
    Reporter:  dons              |        Owner:  simonmar                   
        Type:  bug               |       Status:  new                        
    Priority:  normal            |    Milestone:                             
   Component:  Compiler          |      Version:  7.0.3                      
    Keywords:  seq, evaluate     |     Testcase:                             
   Blockedby:                    |   Difficulty:                             
          Os:  Unknown/Multiple  |     Blocking:                             
Architecture:  Unknown/Multiple  |      Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------

Comment(by simonpj):

 I'm just adding Don's comment and my response from ghc-users.

 Don says: that's a very common idiom. Interestingly, we have:
 {{{
 -- | Strict (call-by-value) application, defined in terms of 'seq'.
 ($!)    :: (a -> b) -> a -> b
 #ifdef __GLASGOW_HASKELL__
 f $! x  = let !vx = x in f vx  -- see #2273
 #elif !defined(__HUGS__) f
 $! x  = x `seq` f x
 #endif
 }}}
 Simon's response: It's very different, I think.

  * `evaluate` is in the IO monad, and (should) guarantee to evaluate the
 argument before proceeding, so if evaluating the argument to WHNF diverges
 or throws a exception, any exceptions thrown (in the IO monad at least)
 after the 'evaluate' should not happen.  For example:
 {{{
 evaluate (throw "first") >> throwIO (userError "second")
 }}}
  should guaranteed to throw "first" and not "second". (The current bug is
 the 'evaluate' doesn't meet its guarantee.)

  * Strict application `($!)` is not in the IO monad, so it merely makes a
 strictness guarantee.  It doesn't guarantee to make exceptions in the
 argument "beat" exceptions in the function.  For example
 {{{
 ((:) $! (throw "second")) $! (throw "first")
 }}}
  does ''not'' guaranteed to throw "first" rather than "second".

 Does that distinction make sense?  Perhaps the contrast is a useful one. I
 wonder where it might be documented?

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