"Simon Marlow" <simonmar@microsoft.com> wrote,
I've added a finalizer rationale document to the repository, under haskell-report/ffi (i.e. the same place as the FFI spec). If you have CVS commit privs, please feel free to modify it, or otherwise suggest changes on this list.
Thanks a lot for the summary. To be honest, by now I am convinced that the Right Thing is to revert back to Haskell finalizers. Reasons: * 2 out of 3 systems regard Haskell finalizers as a non-issue to implement and there exists a prototype implementation for the 3rd system. * Everybody except Alastair seems in favour of reverting back to Haskell finalizers. * Alastair's main counter argument appears to be - potential to introduce race conditions - potential for deadlock We need to place a side condition on what a Haskell finalizer may do (ie, not update IORef's) in the same way as we would have to place side conditions on what a C finalizer may do (ie, not call back into Haskell). So, I am going to revert the spec back to Haskell finalizers for the next RC. I agree with Alastair that we need to add to the spec at the same time a precise statement about what Haskell finalizers are allowed to do (or not do). Manuel