#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
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
