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. _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi