Ptr and ForeignPtr Questions

[Ashley Yakeley]

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.

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:

  const char* foo()
      {
      return "hello";
      }

...since the best the FFI can do is this:

  foreign import foo :: IO (Ptr CChar)

...which is certainly _not_ const-safe.

Perhaps one could have ConstPtrs, which didn't allow writes, and allow 
those in FFI.

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?

-- 
Ashley Yakeley, Seattle WA