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?
Simon
| -----Original Message-----
| From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-
| boun...@haskell.org] On Behalf Of Don Stewart
| Sent: 04 May 2011 04:49
| To: glasgow-haskell-bugs@haskell.org; ezy...@mit.edu
| Subject: Re: [GHC] #5129: "evaluate" optimized away
|
| 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
|
|
| On Tue, May 3, 2011 at 5:13 PM, GHC <cvs-...@haskell.org> wrote:
| > #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 ezyang):
| >
| > One rather user-visible result of this ticket is that we should now
| > discourage the use of the idiom
| >
| > {{{
| > x `seq` return ()
| > }}}
| >
| > I can see a few instances of this in `base`
| >
| > {{{
| > ezyang@javelin:~/Dev/ghc-master/libraries/base$ grep -R '`seq` return ()'
| > .
| > ./Foreign/C/String.hs: go [] n = n `seq` return () -- make it
| > strict in n
| > ./Foreign/C/String.hs: go [] n = n `seq` return () -- make it
| > strict in n
| > ./GHC/IO/Handle/Text.hs: c `seq` return ()
| > ./GHC/Conc/Windows.hs: r `seq` return () -- avoid space leak
| > }}}
| >
| > and there are probably more elsewhere.
| >
| > --
| > Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5129#comment:6>
| > 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
| >
|
| _______________________________________________
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
