Hello, Judging by the silence that greeted my last posts re this a couple of weeks ago I suspect this is of no interest to anyone but me :-( An extra couple of weeks cogitation on this hasn't really changed MHO much (other than I'm no longer so pessimistic about the safety of my <+ operator). Seeing as the FFI seems to be close to finalization I thought I'd have another go. So excuse me if this seems half baked, but am I the only one who thinks the type signatures of utilities like this.. allocaBytes :: Int -> (Ptr a -> IO b) -> IO b ..are rather inconvenient? Wouldn't.. allocaBytes :: Int -> (Ptr a -> b) -> b ..be more useful? To get around this I defined an operator.. infixl 0 <+ (<+) :: (Ptr a -> b) -> ((Ptr a -> IO b) -> IO b) -> b f <+ alloc = unsafePerformIO $ alloc $ \p -> return $ f p (Actually I now think the type of <+ should be.. (<+) :: (a -> b) -> ((a -> IO b) -> IO b) -> b ..so it will work with functions like withCStringLen) This seems to work, but I wasn't entirely comfortable with its safety due to the use of unsafePerformIO. Anyway, perhaps there's a good reason for things having been done this way, but right now I can't see it. So could somebody who understands the reasons for the FFI design decisions and underlying implementation explain why a change such as I have suggested could not or should not be made? Possible explanations that occur to me are.. 1- It's technically impossible. 2- It's unnecessary because FFI users can define their own contraptions like <+ if they want them, assuming the use of unsafePerformIO in this context really is safe (and unsafePerformIO is available). 3- It's undesirable because the existing forms are better in some way. 4- It's undesirable because it would break existing code (not true AFAICS). Thanks -- Adrian Hey