The new wording:

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

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.
FFI mailing list

Reply via email to