Finalizers finalized

[Manuel M T Chakravarty]

Sorry for taking so awfully long with a wrap up of the
finalizer affair, but here it is.

Unanimous agreement:

* Alastair was right: Haskell finalizers require pre-emptive
  concurrency => C-finalizers only in FFI 1.0

Still under discussion:

* Names for the C-finalizer functions:

  - A number of people have called for names other than
    those originally used for Haskell finalizers; in
    particular, an inclusion of the word "unsafe" was
    proposed.

  - Two important points have been ignored in this part of
    the discussion:

    (1) FFI RC 6 already included C finalizers *and* used
        the original names (`newForeignPtr' and
        `addForeignPtrFinalizer') after we discussed this
        point before.

    (2) Hugs Nov2002 already implements the FFI RC 6 API.
        Alastair mentioned that before the release and
        shortly after it was discovered that Haskell
        finalizers won't make it into the FFI spec.

    I think we owe it to the Hugs people to stick to
    `newForeignPtr' and `addForeignPtrFinalizer' now.
    Besides, I also think that these names are better.  As
    Alastair mentioned, these are the only finalizer
    primitives in the FFI, so it is a bit strange if they
    are labeled unsafe.

    Please also note that the unsafeness is different from
    that in other functions that contain the word "unsafe"
    (like `unsafePerformIO').  Hence, I don't think it would
    really make the meaning clearer and being more precise
    in the names would make them pretty long.

    Proposed action: leave the names as published in FFI RC 6

* Alastair proposed the addition of

    void hs_free_stable_ptr (HsStablePtr x);

  The name is consistent with the rest of the FFI C API and
  has already been included into Hugs Nov2002.  Moreover,
  Sven already added

    void hs_free_stable_ptr (HsStablePtr *sp);
    void hs_free_fun_ptr    (HsFunPtr *fp);

  to the CVS version of the spec a while ago.  I am not sure
  whether the "*" in the signatures was a mistake.  Maybe
  the idea was to pass a pointer to the pointer that is to
  freed in and have the freeing function set that to 0L.
  However, I think, it is better to go with the interface
  suggested by free() and already implemented in Hugs.

  Proposed action: Add 

      void hs_free_stable_ptr (HsStablePtr sp);
      void hs_free_fun_ptr    (HsFunPtr fp);

    to the spec.

  [NB: Sven already added the functions with the "*" in the
  signature to GHC's `HsFFI.h'.  These would need to
  change.]

* Should there be a guaranteed execution order for multiple
  finalizers on a single object?  Alastair argues for this
  in

    http://haskell.org/pipermail/ffi/2002-November/000990.html

  There have neither been positive nor negative comments.

  Proposed action: Revise the spec for
    `addForeignPtrFinalizer' to read as attached below.

* `touchForeignPtr', `keepAlive', and `ForeignDependency':
  To be honest, I don't buy into the motivation for
  `keepAlive' and friends from 

    http://haskell.org/pipermail/ffi/2002-October/000942.html

  I'll state my reasons in a direct reply to the above
  message.

  Proposed action: leave `touchForeignPtr' as it is in FFI RC 6

* The `Proxy' story: The discussion seemed to have trailed
    off without a real conclusion.  I'll write a seperate
    email on this.

Any *serious* objections?  (I already executed the above
proposed actions on the CVS version of the spec.)

Cheers,
Manuel

-=-

\item[addForeignPtrFinalizer ::\ ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO
  ()] Add another finalizer to the given foreign pointer.  All finalizers
  associated with a single foreign pointer are executed in the opposite order
  of their addition---i.e., the finalizer added last will be executed first.