- 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
Manuel, "should always have" is unfortunately ambiguous: does it mean "you should ensure that...", or "we believe that..., but we're not completely sure". I suggest changing the last phrase to ...; to avoid this, the programmer should ensure that the result of unsafePerformIO has a monomorphic type. John