John Hughes <rjmh@cs.chalmers.se> wrote,
If the \code{IO} computation wrapped in \code{unsafePerformIO} performs side effects, then the relative order in which those side effects take place (relative to the main \code{IO} trunk, or other calls to \code{unsafePerformIO}) is indeterminate.
I suggest adding:
Moreover, the side effects may be performed several times or not at all, depending on lazy evaluation and whether the compiler unfolds an enclosing definition.
This seems to be a common "gotcha" which it would be wise to warn of.
I added that.
- Great care should be exercised in the use of this function. Not only - because of the danger of introducing side effects, but also because - \code{unsafePerformIO} may compromise typing, for example, when it is used - in conjunction with polymorphic references.
Or maybe it would be better to provide some useful guidance? How about,
To preserve the soundness of the type system, the result of unsafePerformIO should always have a monomorphic type. For example,
listRef = unsafePerformIO (newIORef [])
is unsafe, while
listRef = unsafePerformIO (newIORef ([] :: [Int]))
is type safe. In the first case listRef is assigned type IORef [a], which makes it possible to store a list of one type and fetch it with a different type.
Unfortunately, this example is not directly applicable. As Ross pointed out, it is already ruled out by the determinism requirement. Moreover, `IORef's are neither part of H98 nor of the FFI. The construction of a corresponding example with `Ptr' that uses `unsafePerformIO' deterministically is possible, but IMHO a bit to verbose for inclusion at this point. However, I have changed the above cited warning to read Great care should be exercised in the use of this function. Not only because of the danger of introducing side effects, but also because \code{unsafePerformIO} may compromise typing; in particular, the result of \code{unsafePerformIO} should always have a monomorphic type. This at least describes the typing problem more precisely. Cheers, Manuel