ForeignPtr

Simon Marlow simonmar at microsoft.com
Thu Nov 7 12:10:12 EST 2002


> Ah, got you.
> 
> How about making ForeignPtr slightly more polymorphic so that 
> instead of
> working only on 'Ptr a' it works on 'a'.
> 
> e.g., We'd have:
> 
>   newForeignPtr :: a -> Finalizer a -> IO ForeignThing a

Hmm, interesting.  This allows the implementation to divorce the object
you're interested in finalizing from the object which the finalizer
actually watches.  eg.

  data ForeignThing a = ForeignThing a X

where X is some object with "identity", i.e. an object which is only
explicitly allocated in the IO monad.  Examples are IORef, MVar,
ForeignPtr - it doesn't really matter, as long as you can attach a
finalizer to it and it can't be arbitrary duplicated by the compiler.  

In GHC, this means we could get rid of the ForeignObj# primitive type.

If you want finalizer ordering, as discussed previously, the
implementation would have to be

  data ForeignThing a = ForeignThing a !(IORef [Finalizer a])

(the IORef has identity, so that serves as our X).

> obviously, we'd want to remove the word 'Ptr' from the name 
> of the type.
> Candidates:
> 
>   ForeignProxy, ForeignObj, Foreign
> 
> I think 'Foreign' is an essential part (at least, given the
> restriction to C finalizers) and I favour the first two over the last
> which seems too general.

Maybe "Finalized"?

Cheers,
	Simon



More information about the FFI mailing list