reid at cs.utah.edu
Tue Jun 18 08:07:16 EDT 2002
> In a nutshell: I'm not very happy with the explicit allocation and
> deallocation of the 'foreign import wrapper' thunks. They are an
> artefact of the Haskell implementations and look strange in an
> otherwise GC-ed world...
I think they're explicitly deallocated (and, hence, explicitly
allocated) because C uses explicit allocation/deallocation. The
expectation is that the function pointer will be handed to C and that
C code will be responsible for deallocating the function.
I'm at something of a loss for how GC support would help with your
example. How would Haskell's GC know that the one and only call
to the wrapper had just been made?
Incidentally, I'd like to add a Haskell version of freeHaskellFunPtr
to the C interface:
extern void hs_free_haskell_funptr( HsFunPtr x );
Of course, it can always be foreign exported (and compilers might even
implement it that way) but I think we'll find that every major library
exports its own copy and, since there's only so many obvious variants
on the Haskell name, we'll quickly run into name conflicts which will
then be resolved in the usual ugly way.
I recognize that this is the top of a slippery slope which will
quickly plunge us into a situation of exporting a whole bunch of
functions for manipulating ffi-related datatypes. I'm not sure that's
such a bad thing though.
More information about the FFI