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. In Sept 2001 Ashley Yakeley asked why ForeignPtr couldn't be generalized, i.e. an interface like (slightly modified from the original): data Proxy a -- abstract; for GHC, = Proxy ForeignObj# instance Eq (Proxy a) type Finalizer a = FunPtr (a -> IO ()) -- or IO () for Haskell finalizers newProxy :: Finalizable a => a -> Finalizer a -> IO (Proxy a) addFinalizer :: Finalizable a => Proxy a -> Finalizer a -> IO () withProxy :: Finalizable a => Proxy a -> (a -> IO b) -> IO b touchProxy :: Finalizable a => Proxy a -> IO () class Finalizable a -- things that are boxes around primitive data
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
On first glance, this looks cool. What instances do you envision (assuming I persuaded you that StablePtr and FunPtr should not be)?
How about Int (for file descriptors, etc)?
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 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. Trivial to implement, might require an additional layer of boxing in GHC (maybe in Hugs too - I forget the implementation). -- Alastair
On Thu, Nov 07, 2002 at 04:53:04PM +0000, Alastair Reid wrote:
On first glance, this looks cool. What instances do you envision (assuming I persuaded you that StablePtr and FunPtr should not be)?
How about Int (for file descriptors, etc)?
Ah, got you.
How about making ForeignPtr slightly more polymorphic so that instead of working only on 'Ptr a' it works on 'a'.
That was Ashley's original proposal, but SimonM responded in http://www.haskell.org/pipermail/glasgow-haskell-users/2001-September/002290... http://www.haskell.org/pipermail/glasgow-haskell-users/2001-September/002304... that the extra boxing was unsafe in GHC. Hence the Finalizable class for boxed primitive objects, similar to the way UArray's are presented without exposing GHC's unboxed types.
this already exists in GHC, a side effect of Weak pointers is that they allow finalizers to be assosiated with any value. http://haskell.org/ghc/docs/latest/html/base/System.Mem.Weak.html === addFinalizer :: key -> IO () -> IO () A specialised version of mkWeakPtr, where the Weak object returned is simply thrown away (however the finalizer will be remembered by the garbage collector, and will still be run when the key becomes unreachable). === although I would love to see Weak pointers make it into some spec or another perhaps the FFI is not the right place. (but i wont argue if people want to add them). John On Thu, Nov 07, 2002 at 04:53:04PM +0000, Alastair Reid wrote:
On first glance, this looks cool. What instances do you envision (assuming I persuaded you that StablePtr and FunPtr should not be)?
How about Int (for file descriptors, etc)?
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
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.
Trivial to implement, might require an additional layer of boxing in GHC (maybe in Hugs too - I forget the implementation).
-- Alastair _______________________________________________ FFI mailing list FFI@haskell.org http://www.haskell.org/mailman/listinfo/ffi
-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
participants (3)
-
Alastair Reid -
John Meacham -
Ross Paterson