> > Still hoping ;-) The discussion seemed to stop without reaching a > > conclusion last time. > > I thought it was concluded and the report changed such that all three > compilers which implement the ffi spec can implement it without > receiving a heart, lung and liver transplant.
Then I'll reformulate my question as a patch. Enclosed is a proof-of-concept patch that implements Haskell finalizers in Hugs, which works on some simple tests that I've run. There's nothing particularly clever going on - I'm just suspending execution of the finalizers until the next call to eval(). Is there anything fundamentally wrong with this approach? Possible problems I can think of: - It doesn't work too well with Hugs's cooperative multitasking: don't try to synchronise with another thread from a finalizer. The same problem occurs with foreign calls which re-enter haskell. - It adds a small amount of overhead to eval(); I haven't measured it, but I'm guessing it's not enough to worry about. - If you refer to the ForeignPtr from the finalizer, then the garbage collector will never discover the ForeignPtr is dead. There are GC techniques to avoid this problem, though. I've enclosed a simple test which runs finalizers within finalizers down to an arbitrary depth. Cheers, Simon
patch
Description: patch
testfptr.hs
Description: testfptr.hs