Allocation & Marshalling Question (again)

[Adrian Hey]

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