Fri, 01 Dec 2000 12:53:19 +1100, Manuel M. T. Chakravarty <chak@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@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK