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