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

Alastair Reid alastair at reid-consulting-uk.ltd.uk
Thu Nov 7 10:43:07 EST 2002

Manuel M T Chakravarty <chak at cse.unsw.edu.au> writes:

> The issue came up in a binding to a BDD library currently being
> implemented by Peter Gammie <peteg at cse.unsw.edu.au>.  With BDDs, it
> is important that when you construct a BDD for the same expression
> two times that you get the same BDD (ie, the resulting BDD values
> should be (==)).  The C API of the BDD library represents BDD values
> as pointers that in Haskell land become ForeignPtrs as they need
> finalisers.  This application obviously requires equality on
> ForeignPtrs to be the same as the equality of the underlying C
> pointers.

Nice example.
Though, as I said, this equality test can be implemented using
existing operations.

> I still think that the "new" semantics documented in the FFI spec is
> what a user would intuitively expect.  When you compare two foreign
> pointers, you want to know something about the equality of the
> things being referenced.  You are not interested whether the two
> objects share the same finalizer.  In other words, I think the old
> GHC-Hugs semantics is misleading.

I think it depends a bit on how you think about the objects being compared.
Equality on IORefs and mutable arrays doesn't compare the contents; equality
on pairs, Maybes and arrays does compare the contents.

One difference is that the former are created in the IO world and it
is important to reason about sharing.

The other difference is that the former can be mutated so comparing
the contents isn't very useful.

Which factor dominates?  On the one hand, sharing of ForeignPtrs
matters but, on the other, the only mutation is of the finalizer list


More information about the FFI mailing list