ForeignPtr

[Alastair Reid]

> 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