Ross Paterson [EMAIL PROTECTED] 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
Alastair Reid [EMAIL PROTECTED] wrote,
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
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
Alastair Reid [EMAIL PROTECTED] 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
foreign dependencies can mutate too. they are attached to the
ForeignPtr, not the underlying C Ptr. perhaps ForeignPtr should not be
an instance of Eq so people can provide their own? although, I supose
that is what newtypes are for. is testing if they are 'the same' foreign
pointer efficiently
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
