On Sun, Jun 08, 2003 at 10:36:48PM +1000, Manuel M T Chakravarty wrote:
Done. Done. Done.
Thanks, that's much safer. It's just nitpicking now, but:
Having washed our hands of unsafePerformIO applied to non-deterministic actions, we no longer need the third paragraph, which (though scary) provides no useful guidance:
- 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.
I don't quite agree with this. John's IORef example is indeed outlawed by the determinism requirement. However, it is possible to construct examples that are deterministic, but still dubious from a typing perspective. Let's assume a C routine
void *foo();
that *always returns the same pointer* to a buffer area. To bind this in Haskell as
foreign import ccall foo :: Ptr a
is problematic[1].
I wouldn't consider that an environment-independent value.
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.
Unlike the other restrictions, this one could be checked by a compiler, but perhaps it's too strict. The problem isn't polymorphism as such, but polymorphic storage references, and I claim they're either environment-dependent or ill-typed. I also suspect there may be some perfectly reasonable polymorphic examples, though I can't think of a realistic example offhand. In any case, it's not accurate to call it a function.
Moreover, we could use a stable pointer to store a reference to an IORef in C land and use this to construct something not unlike John's example. In contrast, to John's example, we would always get the same IORef (so the function is deterministic), but could still give it the polymorphic type that it shouldn't have.
I don't see how this will fly. Typo: in 6.2 CTypes, the second and third bulleted paras have T for CT.