On 12/11/2012 16:56, Simon Hengel wrote:
Did you try -fpedantic-bottoms?
I just tried. The exception (or seq?) is still optimized away.
Here is what I tried:
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
main = evaluate (('a' : undefined) `deepseq`
Sounds like a bug, -fpedantic-bottoms should work here. Please open a
ticket.
done [1].
[1] http://hackage.haskell.org/trac/ghc/ticket/7411
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Did you try -fpedantic-bottoms?
Cheers,
Simon
On 08/11/2012 19:16, Edward Z. Yang wrote:
It looks like the optimizer is getting confused when the value being
evaluated is an IO action (nota bene: 'evaluate m' where m :: IO a
is pretty odd, as far as things go). File a bug?
Cheers,
On 12-11-12 11:34 AM, Simon Marlow wrote:
Did you try -fpedantic-bottoms?
Interesting option. And furthermore its doc refers to -fno-state-hack, too.
import Control.DeepSeq
import Control.Exception
main = do
evaluate (('a' : error A) `deepseq` putStrLn hi)
throwIO (userError B)
-O
Did you try -fpedantic-bottoms?
I just tried. The exception (or seq?) is still optimized away.
Here is what I tried:
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
main = evaluate (('a' : undefined) `deepseq` return () :: IO ())
$ ghc -fforce-recomp
Hi Edward,
thanks a lot for your reply.
rnf can be thought of a function which produces a thunk (for unit)
which, when forced, fully evaluates the function. With this in hand,
it's pretty clear how to use evaluate to enforce ordering:
evaluate (rnf ('a': throw exceptionA))
So if I
On 12-11-08 07:12 AM, Simon Hengel wrote:
I was just going to say that I can give at least one counterexample
where this does not hold:
evaluate (('a' : undefined) `deepseq` return () :: IO ())
throwIO exceptionB
But then I realized that here exceptionA is optimized away altogether.
For
And the important observation is: all of them throw A if interpreted in
ghci or compiled without -O, right?
On Thu, Nov 8, 2012 at 11:24 AM, Albert Y. C. Lai tre...@vex.net wrote:
On 12-11-08 07:12 AM, Simon Hengel wrote:
I was just going to say that I can give at least one counterexample
On 12-11-08 01:01 PM, Nicolas Frisby wrote:
And the important observation is: all of them throw A if interpreted in
ghci or compiled without -O, right?
Yes.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
It looks like the optimizer is getting confused when the value being
evaluated is an IO action (nota bene: 'evaluate m' where m :: IO a
is pretty odd, as far as things go). File a bug?
Cheers,
Edward
Excerpts from Albert Y. C. Lai's message of Thu Nov 08 10:04:15 -0800 2012:
On 12-11-08 01:01
Is this related to imprecise exceptions?
http://research.microsoft.com/en-us/um/people/simonpj/papers/imprecise-exn.htm
Antoine
On Thu, Nov 8, 2012 at 12:01 PM, Nicolas Frisby nicolas.fri...@gmail.comwrote:
And the important observation is: all of them throw A if interpreted in
ghci or
Hello Simon,
I think the confusion here is focused on what exactly it is that
the NFData class offers:
class NFData a where
rnf :: a - ()
rnf can be thought of a function which produces a thunk (for unit)
which, when forced, fully evaluates the function. With this in hand,
it's pretty
12 matches
Mail list logo
