ForeignObj and ForeignPtr

[Simon Marlow]

> 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