On Thu, 23 Nov 2000, Manuel M. T. Chakravarty wrote:
I believe that this stuff belongs into the higher-level marshalling library. In fact, it should be instances of more general routines dealing with lists of Storable elements.
Strings require more sophistication because their encoding used in C will be different than Haskell's Unicode. It implies that the API must assume that programmers will not know the length of a C string before actual conversion from a Haskell string (nor vice versa); allocation and translation should be done in one step. Generic Storable versions can be used after the translation from [Char] to [CChar] was done. Or before the translation, producing a C array of HsChar values. But to make it possible to convert strings independently of how exactly charset handling will be done, a few simple functions should be provided. For example ones that I've proposed. They are consistent with bits that are in GHC's FFI now and with what I propose for generic Storable versions.
Again, this belongs into the higher-level marshalling library. Did you have a look at the corresponding routines in C2HS?
Yes, I was inspired by C2HS in a significant way. Handling strings is about the only implementation-dependent thing lacking from the core FFI provided by GHC (and hopefully the official FFI in the future). Handling errors (errno, exceptions) could arguably be the second. But I believe that adding a few higher level functions will make these modules complete enough to write many C interfaces without the need of an additional yet higher level library. All GHC's standard libraries and hslibs should be at some point converted to use a consistent FFI library. This should be done even before Unicode really comes, to make all of them use a proper encoding for OS strings instead of ISO-8859-1 at the same time. These functions are not as high level as I hoped. E.g. there is no wrapper for converting many arguments in an interesting way at the same time, or specialized handlers for out and in/out parameters. I could not think of a good way to express them (making simple things easy and hard things possible, exception safe, and as Haskell 98 conforming as possible). OTOH it makes the library simpler. Dealing with one argument at a time seems to be convenient enough. I hope that the library is small enough for the official FFI. For the convenience of porting the library can be split into implementation-dependent and implementation-independent parts. (I used to have this split but have given up for the moment, because it complicated the module structure, especially when supporting both ghc-4.08 and 4.09). -- Marcin 'Qrczak' Kowalczyk