Patrik Jansson
On Fri, 31 Jan 2003, Jon Cast wrote:
Otherwise, though, see my other post on this subject: unsafePerformIO will perform its action when the variable is accessed, so you can't write a Haskell program which differentiates between what any compiler actually does and running the variable allocations before main.
If you initialize this "global variable" with a value from a file which is changed by main (or over time) then order does matter.
1. Why would you do this? In any case, the solution adopted in C (initialize the global statically with ``no value'' (0, NULL, Nothing, etc.) and overwrite it at a fixed point in main or elsewhere) should be good enough. 2. In any case, my claim is actually: If a :: IO alpha, for monomorphic alpha, and a's only interaction with the state consists of either creating new IORefs or accessing IORefs created by a, then unsafePerformIO's result is unaffected by the order of evaluation.
I claim unsafePerformIO is very often unsafe
It's always potentially unsafe. However, it is always possible to prove that a particular application is safe (under sufficiently stringent conditions, of course).
- the question is more like if the "level of unsafety" is acceptable for a particular application.
There is no "level of unsafety". There is only the level of trust you put in your proof of satisfaction of unsafePerformIO's proof obligation and your view of the acceptability of the portability restrictions of your proof.
/Patrik
Jon Cast