Sorry to ask this again, but I didn't understand the answer last time, and the need to explicitly free StablePtr's, Haskell FunPtr's and close foreign handles, etc, is surely a serious wart in the FFI spec.
I don't understand part of this. StablePtrs exist so that you can hand them to C. [Even if you were to use conservative GC with C] C needs to tell Haskell when it is finished with the StablePtr. It does this an explicit free function. Haskell's GC cannot safely free StablePtrs because the assumption is that C has a pointer to it and has not yet explicitly freed it. In short, the defining feature of StablePtrs is the need to use an explicit free function to delete them. Remove this feature and they really don't buy you much. Is there another use for StablePtrs where this is not an issue? The same seems to apply to FunPtrs and I'm not sure what you mean by "foreign handles"
In Sept 2001 Ashley Yakeley asked why ForeignPtr couldn't be generalized, i.e. an interface like (slightly modified from the original):
On first glance, this looks cool. What instances do you envision (assuming I persuaded you that StablePtr and FunPtr should not be)?
type Finalizer a = FunPtr (a -> IO ())
Let's add that to the FFI spec - useful whether we adopt proxies or not. -- Alastair