The Death of Finalizers

[Alastair Reid]

> [snip] How sad.  It's an unfortunate hole in the specification and I
> hope someone will come up with a way of fixing it someday.

I don't think it'll happen until preemptive concurrency is more widely
implemented.

> In the meantime, I'm glad we have got a new function
> atomicModifyIORef which I for one will use, when it gets into GHC's
> regular release.  It's really nice that we can use laziness to
> safely update a mutable value without blocking.  Another nail in the
> coffin for Standard ML.

Do we still have atomicModifyIORef?

I don't know that there's that much point now that Haskell finalizers
are gone.  I don't have a strong objection (esp. since it seems every
implementation now has it) but it doesn't seem so necessary now.

> I think the addForeignFinalizer function or whatever it is should
> nevertheless be renamed to addUnsafeForeignFinalizer (and likewise
> for newForeignObject).

I see some sense in that argument but:

1) I don't especially like that the only standard way of doing finalizers
   is labelled 'unsafe'.

2) We started cutting release candidates for Hugs yesterday using the old
   names.  Sigh...

Again, no strong objection but I'd do it differently.

> Also I suppose Alastair's hs_freeStablePtr function which allows you
> to do it from C, or whatever, will have to be added.

I've just added 

  void hs_free_stable_ptr(HsStablePtr x);

to Hugs in the hope that it will make it into the next release candidate

The capitalization change is for consistency with 

  void hs_perform_gc(void);

and I hope it will be what we put into the FFI report.

> I hope Alastair will forgive me for engaging him in such a lengthy
> argument, when he turns out to have been right all along.

I wish I'd come up with convincing arguments faster.

--
Alastair