ANN: H98 FFI Addendum 1.0, Release Candidate 10

[John Hughes]

>
> > > - 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