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

Alastair Reid alastair at reid-consulting-uk.ltd.uk
Wed Nov 6 14:32:47 EST 2002


[Thread moved from the library cvs mailing list]

Simon Marlow:
>   - Fix the Eq instance for ForeignPtr to match the behaviour
> specified by the spec.  Two ForeignPtrs are equal iff their
> underlying Ptrs are equal (previously they were equal iff they were
> the same ForeignPtr).

Alastair Reid:   
> Hmmm, the Hugs implementation goes for 'same foreignptr' and, to me,
> that seems to make more sense.
> 
> I wonder why the spec changed the semantics from that in the 
> Hugs-GHC spec?

Simon Marlow:
> I don't have any strong opinions on the matter, I just changed it to
> match the spec because someone complained.
> 
> Do you have an example where the previous behaviour is more useful?
> Perhaps it should be brought up on the FFI list.

I don't have a really compelling example just a nagging feeling and
worry that a design is being changed without (as far as I can recall)
any discussion of the matter.

Here's some questions that might help understand the difference:

1) Is there any practical difference between the old semantics and the new?

   There used to be a big difference because ForeignObjects supported
   an operation to replace the underlying Ptr.  Equality on mutable
   objects is clearly different from equality on the contents of the
   mutable objects.

   But, ForeignPtrs with the same Ptr but different finalizers are different
   and the finalizer list _is_ mutable so there is a useful difference.

   The difference between two ForeignPtrs which contain the same Ptr is
   especially clear if we think about what happens if the first one dies
   before the second or the second is the first to die.

2) Can either semantics be implemented in terms of something we already have?

   We can implement the new semantics using castForeignPtrToPtr.

   There's no way to implement the old semantics using other existing
   operations.  Even if there was a way to extract the list of
   finalizers (and assuming we're happy using pointer equality on the
   finalizer functions), we still couldn't implement it because
   ForeignPtrs are, effectively, mutable objects.

In short, I can see that switching to the new semantics (ForeignPtr
equality == equality of contents) removes something we had before and
doesn't add anything new but I don't have any examples of where it is
actually useful.  (I also have no examples of where the new semantics
is useful.)

I should also say that I have no strong feelings on the matter - I'd
just like to hear someone argue that the change is an improvement or
be pointed at an old discussion on the subject.

--
Alastair




More information about the FFI mailing list