My point here is to know, what's the reason for the different behaviour, rather than discussing the correctness of using unsafePerformIO.
The reason is this: GHC uses a lazy evaluation strategy, as opposed to fully-lazy. Under lazy evaluation, the unsafePerformIO expression in your example will be evaluated each time main is invoked. When -O is turned on, GHC performs some transformations on the code that have the effect of changing the evaluation strategy to "almost fully-lazy". That is, there will be some more sharing, but not necessarily as much as you would get in a compiler that implements fully-lazy evaluation. Indeed, even without -O, you might get a bit more sharing than you would under pure lazy evaluation. Of course, you should never write any code that depends on any of this. Cheers, Simon
Ok, thanks for all your comments.
But I think that the examples haven't much to do
with the core-to-core optimisations, because I've also used
a modified version --modified be me ;-) -- of ghc5.04.3,
where only a modified simplifying is done. The modifications
are small: Do Inlining only for values, do only trivial eta-expansion
(not for case, let and so on) , and some other "small" things.
But with this modified compiler, the same problem comes up.
I didn't modify things after simplifying, espcially generating STG-Code
or transforming (optimising) this code.
I think it has something to do with the STG-Code generation or
with normal code generation, and it depends on the fact, if
the function is exported or not.
Any hints in this direction???
Thanks,
David
----- Original Message -----
From: "Simon Marlow"
My point here is to know, what's the reason for the different behaviour, rather than discussing the correctness of using unsafePerformIO.
The reason is this: GHC uses a lazy evaluation strategy, as opposed to fully-lazy. Under lazy evaluation, the unsafePerformIO expression in your example will be evaluated each time main is invoked.
When -O is turned on, GHC performs some transformations on the code that have the effect of changing the evaluation strategy to "almost fully-lazy". That is, there will be some more sharing, but not necessarily as much as you would get in a compiler that implements fully-lazy evaluation.
Indeed, even without -O, you might get a bit more sharing than you would under pure lazy evaluation.
Of course, you should never write any code that depends on any of this.
Cheers, Simon
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
participants (2)
-
David Sabel -
Simon Marlow