> perhaps ForeignPtr should not be an instance of Eq so people can > provide their own?
Note that if we did this, we'd want to consider adding an operation eqForeignPtr :: FP a -> FP a -> Bool FP b -- possible variant but not very useful which lets people test equality of the container and not the contents. In fact the more I think on it, the more convinced I am that the Eq instance should compare contaner equality and not contents equality. The reason is that I believe Eq instances should follow the following design rule: Eq instances should compute observational equivalence I believe this is satisfied by all Haskell98 types, all the usual extensions (IORefs and friends) and by derived instances of datatypes. Just to be clear what I mean by observational equivalence, consider comparing two IORefs x and y using this code: eq x y = do a <- readIORef x writeIORef (a+1) b <- readIORef x return (x==y) Obviously, this code is a bad way to test if two IORefs are the same IORef but the point is that we can observe the difference between them. Similarily, with ForeignPtrs, adding a finalizer to one and not the other and then watching for when the finalizer runs is a way that we might observe differences between two FPs. What I don't mean by observational (in)equivalence is this: One might be able to distinguish two data structures of type [Int] (say), by observing how much memory they consume. This is perfectly true but Haskell semantics doesn't let you observe this so we'll rule any such 'observations' as irrelevant or invalid. -- Alastair ps Careful reading will reveal that I still haven't proposed a concrete use for eqForeignPtr. So far, I'm relying on a combination of gut instinct and the fact that we (i.e., me plus one or more of my coauthors at the time (Simon PJ, John Peterson, and Simon Marlow)) did consciously decide to use one semantics instead of the other when we designed MallocPtrs/ForeignObjs/ForeignPtrs originally. I thought about it a good deal harder when I added them than I claim to have thought about them in the last couple of days. _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi