["Simon Marlow" <simonmar@microsoft.com>] RE: cvs commit: fptools/libraries/base/Foreign ForeignPtr.hs

[Carl R. Witty]

Alastair Reid <alastair at 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