Finalizers 2: Bayou Justice (and Weak pointers to boot...)

John Meacham john at
Fri Oct 11 23:30:19 EDT 2002

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
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 Meacham - California Institute of Technology, Alum. - john at

More information about the FFI mailing list