Alastair Reid <alastair@reid-consulting-uk.ltd.uk> writes:

...

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.

My vote would be for Eq ForeignPtr to test the contents. I guess the correspinding design rule would be: Eq instances should compute the most precise equivalence which is commonly useful. I would say that for IORef, etc., observational equivalence is "commonly useful", so that's the correct definition of Eq. On the other hand, for ForeignPtr, contents equality is "commonly useful". We've seen the example of the BDD package; contents equality will also be useful for any C library with an "intern" or "hash cons" operation. As far as I know, nobody has yet come up with a use for container equality for ForeignPtr, but I agree that we should have an eqForiegnPtr just in case. Carl Witty