For the record, I am strongly in favor of Haskell finalizers, if a Mutable State extension were to be written, then it will have to address the issue with one of the solutions mentioned in this thread, but among other things, not having haskell finalizers seems to imply that we would need to add Weak pointers to the FFI.
right now the only way to express dependencies between ForeignPtr's is via calling touchForeignPtr from the finalizer of another ForeignPtr, without the ability to call haskell from the finalizer this becomes impossible. The ability to tie the liveliness of ForeignPtrs together is quite important for many applications. Weak pointers would solve this issue, but haskell finalizers seems like a much better/simpler solution. not having this feature would make much of the foreign interfaces that exist today impossible or impractical. Just musing about the need some people have for ForeignPtrs to be deallocated deterministly, perhaps something like C#'s 'using' construct is in order which would enforce a stacklike allocation policy for ForeignPtrs... perhaps usingForeignPtr :: IO (ForeignPtr a) -> (ForeignPtr a -> IO b) -> IO b which guarentees the ForeignPtr allocated by the first computation will be finalized by the time the entire computation is executed. although perhaps this is not useful or a different type would be in order.. just throwing it out there... of course the same constraints one places on alloca and with* would be needed. and if we are adding things to the FFI spec, how about the empty data declaration? it is painfully simple to implement and would make FFI code a lot cleaner as it tends to depend heavily on placeholder types.. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --------------------------------------------------------------------------- _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi