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