haskell finalisers driven underground

[m v]

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