> 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
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
