Ross Paterson <[EMAIL PROTECTED]> wrote, > 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
Why is this ruled out? hash_bytes returns a `CInt', which is a monomorphic type. > 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 Yes, and that's nothing that we want to rule out. A standard idiom for obtaining constant values from C is -= In C land =- int my_const () { ... return ...; } -= In Haskell land =- const :: Int const = unsafePerformIO my_const foreign import ccall my_const :: IO Int All that's required here is that my_const() is constant within a program run. Of course, I could have given a pure type in the foreign import in this simple example, but that's not different from an explicit `unsafePerformIO' and it is easy enough to construct an example where this is not possible. > (b) the declaration contains incorrect type information. I guess, that's open to debate; ie, depends on how you interpret C types in Haskell. Manuel _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi