Finalizers strike back

[George Russell]

Alastair Reid wrote:
> 
> > [snip] I'm not sure I really understand the problem.  The FFI
> > standard (Release Candidate 4, the one I have printed out here) does
> > not define IORefs, and of course Haskell 98 doesn't either.
> > Therefore, although this code is broken, this particular example
> > doesn't matter if all we are considering is code written in Haskell
> > 98 + FFI.
> 
> If there's no shared mutable Haskell state, writing finalizers in
> Haskell buys you little - what does a finalizer do other than cleanup
> shared state?  (Note that it doesn't cleanup unshared state - what
> would be the point?)
[snip]
> What I hear you saying is that the FFI standard should depend on a
> concurrency standard.  I think there was a strong sentiment that we
> should avoid this.  I agree though that it is necessary if we allow
> Haskell finalizers.
[snip]
I think we should remember that the FFI standard has to address various
audiences
(1) those who want to implement portable code in just FFI + Haskell98.
This group does not have access to functions for conveniently manipulating
mutable state, therefore Alastair's problem with IORefs will not be a problem
for them.  However Haskell inside finalizers will at any rate not harm them.  Furthermore
it is incorrect to say that just because there is no Haskell mutable state, there
is no reason such people may want it to be possible to call Haskell while a finalizer
is running.  Consider someone who, say, calls out from Haskell to Java (to do funny
graphics, say) and writes a finalizer which calls Java code.  At the same time, they
also want to do some completely separate pure computation in Haskell, which is made
available to Java.  Since Java at least does have preemptive concurrency, while
it is running at all, it is perfectly possible that Java will call the Haskell computation
while the Java finalizer is running.  You want a license to make the roof fall in at this
point; I don't think you should have it.
(2) those who want to implement portable code in FFI + Haskell98 + something else.
(I suspect this is the larger group.)  To discuss this at all we simply have to
speculate about what "something else" might be.  One obvious "something else" is 
mutable state.  Alastair is assuming that "something else" is IORefs but not MVars.
However I assert this is implausible or at least unfortunate, because for reasons I've
explained, it would normally be a good idea for implementations and programmers to provide
and use MVars, even if they do not provide and use concurrency, since otherwise you
can't write functions like Alastair's newObject and killObject without making unnecessary
assumptions about the properties of the implementation.  If NHC does not provide MVars,
I think it should.  I apologise to Malcolm, but in any case I doubt if implementing MVars
in a world with only one thread would cost him a great deal of effort.

To sum up, it's NOT that I want the FFI standard to depend on concurrency.  It's once again
that I don't want the FFI standard to depend on the absence of concurrency (as Alastair's
IORef code does).