> > Then I'll reformulate my question as a patch. [...]
> > Is there anything fundamentally wrong with this approach?
>
> I still maintain that getting this to work, testing it and,
> especially, maintaining it is a lot of work.
Isn't it worth a little effort? Requiring finalizers to be foreign
functions is a serious wart in the FFI, especially when we're strongly
advocating that as much marshalling should be done in Haskell as
possible.
As for the testing and maintenance, you can see from the patch that the
changes are quite small and mostly obviously correct. The only
difficult correctness property is whether it's ok to have eval() invoke
runIO() and thereby eval() recursively, but the reasoning is simple:
from eval() you can already call a foreign function, and foreign
functions can invoke foreign-exported Haskell functions, which in turn
re-enter eval() through runIO(). So the patch doesn't add any new
invariants.
You do have to worry about the impact of running Haskell finalizers at
any point during execution of Haskell code. Since you can't do any
concurrency synchronisation between the finalizer and the main Haskell
thread, shared access to mutable data is impossible. This is just
something you'd have to document carefully (note, it's not something you
can do with the current finalization mechanism either, but there it's
obvious).
> [For example, you
> mention that finalizers that point to the object they finalize don't
> work. I guess we could fix that by adding GHC-style WeakPtrs.]
This isn't as big a problem as it sounds. The finalizer can refer to
the Ptr, just not the ForeignPtr. If it is essential to refer to the
ForeignPtr (I can't think of a reason why it should be), then we could
change the spec so that it was passed as an argument to the finalizer.
Cheers,
Simon
PS. I'm sorry to keep banging on about this. Ultimately it doesn't
really matter to me that much, since I only really use mallocForeignPtr.
I guess I was just intrigued to see if the problem was really as
difficult as we'd thought.
