Ptr and ForeignPtr Questions

[Ashley Yakeley]

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 
like this:

     const char* foo (struct SomeLinkedList*);

...you have no choice but to write 'impedance-matching' code for that 
function.

>structs are not allowed as arguments to foreign imported
>functions.

Exactly! And neither are const pointers. But argument const-ness, at 
least, can be safely ignored.

-- 
Ashley Yakeley, Seattle WA