Oops, I sent the attached document to the wrong mailing list. This is a comment on SimonM's finalizer document. I decided to comment rather than edit since my comments require more than tweaking the odd word here and there. -- Alastair Things you mights add are: eg(1) in composite finalizers: This would be handled just fine by C finalizers if addForeignPtrFinalizer guaranteed to execute finalizers in reverse order of their addition. This seems like a reasonable thing to specify since addForeignPtrFinalizer is much less useful if this guarantee doesn't hold and because it is easy to implement. eg(2): isn't too convincing since you could easily write the same thing in C. I expect you could find something more convincing with a little effort. Communicating with a foreign runtime/garbage collector: I remain unconvinced that this example has been worked out in detail and believe that if it were worked out in detail we'd either find that all George needs is to be able to call into the _runtime system_ during a Java GC (doesn't require Haskell finalizers) or that he requires a much more intimate relationship with Haskell's GC (requires a lot more than the FFI provides). Other cleanups: 1) Unsavouriness of exporting &free seems like a judgement an impartial witness would avoid. 2) Whilst "the philosophy of the FFI is to move as much marshalling machinery into Haskell as possible," the existence of an ffi suggests that foreign code does have a useful role and one could argue that finalizing foreign objects is one of those roles. Manipulating mutable state and communicating with other threads: I don't see how adding concurrency strengthens the argument for Haskell finalizers. Adding mutable Haskell state doesn't seem to strengthen it either. Indeed, I assume the existence of mutable Haskell state in arguing against Haskell finalizers. Arguments against: Adding Haskell finalizers drags in many concurrency issues for programmers: - potential to introduce race conditions - potential for deadlock As with most concurrency issues, the resulting bugs are easy to introduce, hard to reproduce and hard to track down. Adding Haskell finalizers has a high implementation burden for those who have not already implemented preemptive concurrency - greatly increasing the complexity of implementing Haskell + FFI (+ mutable state, of course - but that is a trivial thing to implement). The complexities introduced seem out of line with the problem being solved. Implementations/Hugs: You say: "There is some doubt over whether the patch is safe as it stands:" I say: "There is no doubt that the patch is unsafe as it stands:" Implications of allowing Haskell finalizers in non-concurrent systems/Mutable state: You omit my argument that, since the primary goal of finalizers is to modify mutable state, Haskell finalizers which do not modify mutable Haskell state will be of little use. All they will be able to do is lookup objects in immutable Haskell state and invoke C finalizers to do their work - a significant limitation. (In fairness, I will say that useful information might be stored in the finalizer closure so actions like looking up an object in a binary tree of all live objects (say) might be avoidable with a little effort.) Interaction with co-operative concurrency: You say (though your final paragraph suggest you don't insist on it): One might argue that since you have to do this anyway in Hugs - another thread can only get control at an explicit yield point - doing it for finalizers too isn't so bad. I say: There is a world of difference between being delayed for an unknown, finite amount of time and being delayed for an unbounded, potentially infinite amount of time. (This is why vague concepts like 'fairness' are useful in reasoning about scheduling - you don't know when you will run but you know you will get a shot sometime.) Proposals: Add: 4) No change to the spec for the time being, while we evaluate the need and cost of implementing Haskell finalizers in a range of implementations. Note that upgrading from C finalizers to Haskell finalizers would only require that we say that finalizers are invoked with the equivalent of a 'safe' ffi call instead of an 'unsafe' ffi call and, no doubt, the addition of some convenience functions. I don't think this is the same as (3)