In the course of trying to find out GHC's status quo of typing foreign declarations and scribbling together the forthcoming typing rules, I stumbled over ForeignObj/ForeignPtr. There was a lively discussion about this some time ago IIRC, but I'm unsure about a few things:

* ForeignObj has been deprecated for a long time, but we should still keep it in the FFI for a transition time and pass the associated Addr when calling out, correct?

Yes, at least another major release or two.

* Does it make sense to allow ForeignObj/ForeignPtr as a prim_result? I think it doesn't, because the non-Haskell side can't know if and when the finaliser has been run.

That's right, ForeignPtrs exist inside the Haskell world only. When a ForeignPtr is passed outside, it is passed as a plain address, and an address cannot be converted back to a ForeignPtr for returning to Haskell.

* What did we conclude about the lifetime rules? Should ForeignObj/ForeignPtr arguments be handled specially by the FFI or is {touch,with}Foreign{Obj,Ptr} required? I'd opt for the latter, but the current FFI docs seem to imply a special handling. :-P

I'd prefer to keep the "special" handling. Otherwise, we might as well disallow ForeignPtrs as arguments to foreign import, because you'd end up writing withForeignObj f $ \ p -> c_fun p all the time. Much simpler to make this automatic, and in some sense the "special" behaviour is really the expected behaviour (or rather, the alternative behaviour is simply not useful).

On the other hand, I can't see anything special in the code generated by GHC. Hmmm...

That's because it got lost after some changes to the pre-code-generation passes in GHC 5.00. It's on my list of things to fix. Cheers, Simon