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
