addForeignPtrFinalizer

[Alastair Reid]

> It's awkward as a user with a fairly big
> application (namely George) is inconvenienced by it.

I remain unconvinced that this is an issue.  

George, can you describe what the entrypoints you require are in more detail?

> It's awkward because it requires a subtle side condition on what is
> a valid finaliser that is going to trip up users and cause strange
> errors.

It is the same side condition we place on unsafe calls.

> This awkwardness is tolerable if it simplifies the implementation a
> lot (as in avoids having to implement pre-emptive concurrency). 

See my other posting this morning on why Haskell finalizers are of no
practical use without adding concurrency primitives which support
blocking.

> It is not tolerable if it is just a matter of verifying that an
> existing implementation proposal does indeed work (or even if it
> requires tweaking that proposal).

Another valid goal is portability.

We can specify a low bar now and raise the spec later.  For example,
at present the spec is that the finalizer is equivalent to an unsafe
ccall, we can strengthen that spec to allow safe ccalls too later (and
once we can do that we can extend the spec with convenience functions
which allow naked Haskell finalizers).

A