ANN: H98 FFI Addendum 1.0, Release Candidate 10

[Manuel M T Chakravarty]

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