qforeign-0.62

[Marcin 'Qrczak' Kowalczyk]

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