[Alastair Reid <alastair@reid-consulting-uk.ltd.uk>] Re: cvs commit: haskell-report/ffi finalizers.txt

[Simon Peyton-Jones]

When it comes down to it, I don't think we are that far apart.

1.  Everyone wants a C-finaliser interface; it's very convenient.  So it
should be in the spec.  It's probably a good plan to specify that such C
finalisers must obey the constraints of an 'unsafe' foreign import.

2.  It is clear that GHC at least will offer a Haskell-finaliser
interface, and that some people will use those Haskell finalisers; they
already do.   So it's desirable that they should be in the FFI spec so
that there's a standard for what they look like.

3.  We do not want the spec to require mutable state or concurrency, and
indeed Haskell finalisers make sense (albeit are much less convincing)
without such extensions.  Still, I think the spec should warn explicitly
that in the presence of mutable state care must be taken by the
programmer, because the finaliser can run at any time wrt the "main
program".

4.  The spec makes no guarantees about promptness.  Each implementation
may want to add notes about promptness.  For example, Hugs will say that
C finalisers will run much more promptly than Haskell finalisers (if it
supports the latter at all).


I think that the only real point of difference is that Alastair would
rather we did not even specify Haskell finalisers in the FFI spec,
because doing so encourages non-portability.  I don't agree about that;
I think people will use Haskell finalizers anyway, so we should specify
them.

Simon