Ptr and ForeignPtr Questions

[Manuel M. T. Chakravarty]

Ashley Yakeley <ashley@semantic.org> wrote,

> At 2001-09-23 19:14, Manuel M. T. Chakravarty wrote:
> 
> >Hmm, we must be misunderstanding each other.  Given that you
> >have
> >
> >  foreign import strcat :: Ptr CChar -> Ptr CChar -> IO (Ptr CChar)
> >
> >How do you want to know whether the C prototype is
> >
> >       char *strcat(char *dest, const char *src);
> >
> >or
> >
> >       char *strcat(char *dest, char *src);
> 
> 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.)

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.  And if you have written them
yourself, adding a function prototype shouldn't be much more
work.

> But it looks like you want to be able to arbitrarily import any C library 
> function. Of course this means a map from C functions to Haskell 
> functions.
> 
> In the case you gave Haskell could get away with calling strcat using 
> this:
> 
>   char* strcat(char*,char*);
> 
> ...even if the function had actually been defined like this:
> 
>   char* strcat(char*,const char*);
> 
> This is quite safe from a 'const' point of view. More difficult is this:

The only good reason to actually emit prototypes by the
compiler is to check them against the prototypes in an
already existing C header file for the same library.
However, in this case, the above would lead to a type error
when compiling the C code.

> At 2001-09-23 19:21, Manuel M. T. Chakravarty wrote:
> 
> >If you are writing a Haskell binding to a large C library
> >that has hundreds of functions, it is extremely unattractive
> >to write "impedance matchers" like `MyModule__StringCopy'
> >manually.
> 
> I'm taking an approach similar to JNI, in which the user defines in C 
> what has been declared in Haskell. But what you want to do is to allow 
> the user to declare in Haskell what has been defined in C, obviously a 
> more ambitious goal. Const pointers are not your only worry; how would 
> you deal with structs?

structs are not allowed as arguments to foreign imported
functions.

Manuel