qforeign-0.62

[Manuel M. T. Chakravarty]

"Marcin 'Qrczak' Kowalczyk" <mk167280 at zodiac.mimuw.edu.pl> wrote,

> 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.

To me it seems as if we should seperate conversion from
[Char] to [CChar] from the actual marshalling of CChar.  Why
is it an advantage to lump it all together?

In other words, I don't really agree with ``But to make it
possible to convert strings independently of how exactly
charset handling will be done, a few simple functions should
be provided.''  It seemingly makes the conversion
independent, but it makes the low-level FFI module (that's
where I understand you propose the routines to go) dependent
on the conversion, which I don't like to be honest.  But
maybe I am missing something.

Simon Marlow <simonmar at microsoft.com> wrote,

> I think Marcin is right in that C Strings are special (unfortunately).
> This interface seems reasonable, and simple.  Do we have any objections?

My main objection re Strings at the moment is that I would
like to seperate the encoding an marshalling business and
use for marshalling just instances of generic list
marshalling.  This would simplify the structure IMHO.

> > 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.

As the high-level library is meant to be completely portable
(in the sense that it delegates all non-portable work to
lower-level libraries), I don't see much advantage in
avoiding the need for using it in some applications.

> 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.

I am not arguing against you structure - as you know I am
quite happy with most of your proposals.

> 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).

Hmm, but I think, we really want to have this split in the
"official" FFI libraries.  It simplifies the work of other
Haskell implementors (eg, the York people) a lot, I think.

Cheers,
Manuel