ANN: H98 FFI Addendum 1.0, Release Candidate 10

[Ross Paterson]

The new wording:

  \code{unsafePerformIO} may compromise typing; to avoid this, the programmer
  should ensure that the result of \code{unsafePerformIO} has a monomorphic
  type.

rules out the following:

	my_hash :: Storable a => a -> Int
	my_hash a = fromIntegral $ unsafePerformIO $
		allocaBytes (sizeof a) $ \p -> do
		let size = fromIntegral (sizeOf a)
		c_memset p 0 size
		poke p a
		hash_bytes p size

	foreign import ccall unsafe "memset"
		c_memset :: Ptr a -> CInt -> CSize -> IO ()
	foreign import ccall unsafe
		hash_bytes :: Ptr a -> CSize -> IO CInt

I still claim that the problem isn't polymorphism itself, but creating
polymorphic references, and that is always environment dependent.

Manuel writes:
> 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].

(a) It's constant across a run of the program, but its value still depends
    on the environment, and
(b) the declaration contains incorrect type information.