Ptr and ForeignPtr Questions
Sun, 23 Sep 2001 23:54:26 -0700
At 2001-09-23 23:12, Manuel M. T. Chakravarty wrote:
>> I was just hoping for GHC to be able to spit out headers for 'foreign
>> import' functions that the user could then define. This merely means a
>> map from some restricted set of Haskell function types to C types.
>Functionality like that is not part of the FFI. However, it
>would surely be possible to write an extra tool that
>accomplishes just what you want. (It was a general design
>rule to avoid in the basic FFI features that would be
>complicated to define/implement and can as easily be
>implemented by a tool.)
Right. This would be very similar to the 'javah' tool used in the Java
world. That works on compiled .class files, I suppose the equivalent
would be a module that "plugged in" to the GHC "motherboard".
>Moreover, the case where you bind to existing C functions is
>much more common than where you bind to C functions that you
>have written yourself.
Right, but it's a more ambitious goal for the FFI designer, at least if
they want to do it completely. As you point out, there are restrictions
on just what existing C functions you can bind to. If your function looks
const char* foo (struct SomeLinkedList*);
...you have no choice but to write 'impedance-matching' code for that
>structs are not allowed as arguments to foreign imported
Exactly! And neither are const pointers. But argument const-ness, at
least, can be safely ignored.
Ashley Yakeley, Seattle WA