Ross Paterson <ross@soi.city.ac.uk> wrote,
On Mon, Jan 20, 2003 at 11:03:36PM +1100, Manuel M T Chakravarty wrote:
Hence, I propose to leave the definition in the spec as it was; ie, the equality of ForeignPtrs is defined via the vanilla pointer that they encapsulate.
However, if you generalize ForeignPtrs (which I hope you will) this would require Eq on the underlying type. I guess this is no great hardship for the types people want to use it with.
We actually would have two alternatives: (1) We could define instance Eq a => Eq (ForeignObj a) where x == y = foreignObjToObj x == foreignObjToObj y and hence always reduce equality of ForeignObjs to the equality of the base type. (Where this equality doesn't exist, we just don't have an equality on the corresponding ForeignObjs, but they are otherwise still usable.) (2) We could have a builtin instance Eq (ForeignObj a) that implements equality by object identity and define ForeignPtr as follows: newtype ForeignPtr a = ForeignPtr (ForeignObj (Ptr a)) instance Eq (ForeignPtr a) where (ForeignPtr x) == (ForeignPtr y) = foreignObjToObj x == foreignObjToObj y Alastair could, then, still get at his ForeignPtr-equality-as-identity definition whenever he wants. I lean towards (2). In fact, it is one more argument for this generalisation of ForeignPtrs. Hence, I propose that we incorporate this generalisation unless there are any serious objections. Cheers, Manuel