qforeign-0.62

[Marcin 'Qrczak' Kowalczyk]

Fri, 01 Dec 2000 12:53:19 +1100, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> pisze:

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

Efficiency, and the fact that combined conversion+marshalling
operations are convenient anyway.

I don't want to make passing strings to C functions unnecessarily slow
because of Unicode. They will be slower than 8-bit Chars no matter what,
but I hope not too slow if done well.

The default conversion between Unicode and the local byte encoding is
implemented in C (my library uses iconv). It would be silly to store
the string in a C array of HsChars, call iconv to transform it to an
array of chars, and read it as a a list of CChars only to store it
back to a newly allocated array of chars. The former array already
looked like what needs to be passed to the C function! Similarly in
the other direction.

I've already implemented this, but haven't measured efficiency of
various variants yet, nor how much does the conversion slow down the
whole process compared to non-Unicode variant.

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

I'm afraid it's unavoidable in practice.

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

So we would have to provide conversion stubs doing simple casts between
Chars and CChars now, to make the code using it work also in future,
when the conversions become non-trivial. Otherwise how users will
translate between String/HsChar[] and [CChar]/char[]? And we don't
know yet how the conversion interface will look like.

Since the string almost always needs to be translated before
marshalling, it makes sense to provide combined variants anyway.

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

It avoids introducing a dependency on an additional tool. Especially
if the tool evolves independently from compilers, has its own version
incompatibilities, needs to be installed separately and updated after
the compiler update etc. Let's keep things simpler.

I don't see an advantage in requiring to use a separate tool to get
reasonable convenience. There is little to be added to the basic
Foreign module to make it quite complete and usable alone.

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

Surely it will be split again when it's finished.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTÊPCZA
QRCZAK