outlawing Haskell finalisers / eliding them from the language is a futile exercise ... it will just drive them underground like (using a previous example ) ....
import Foreign
foreign import ccall "wrapper" mkfoo:: (Ptr a -> IO ()) -> IO (FunPtr (Ptr a -> IO () ))
main = do p <- mallocBytes 64 foo <- mkfoo (\y->print x) newForeignPtr p foo print x where x = sum [1..10000]
the result of this (using hugs) yields an error as expected .... Main> main INTERNAL ERROR: freeMallocPtr but the utility of haskell finalisers is such that wrapper code like the above is to be expected, which introduces it's own problems. As far as I can see there are no gaurantees for safety using C finalisers as opposed to haskell finalisers so we may as well have the convenience of haskell finalisers. on the finalisation issue, previouse memo's included ... 2) Block the finalizer until the main thread completes evaluation just as GHC does. Blocking the finalizer would require all Haskell implementations to implement preemptive concurrency. This is thought to be an excessive burden. another memo had ... c finalisers are good enough .... I think both propositions bear further examination. 1) c finalisers are good enough... are they ? perhaps I need to justify why haskell finalisers will be driven underground. suppose we have a c routine returning malloc'd memory. Who is going to write a c routine just to free it ? 2) "preemptive concurrency an excessive burden", is preemptive concurrency the only solution ? If it is in what sense is it an excessive burden ? From an implementation point of view or from an operational point of view. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail