qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,
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.
So far, we have handled similar cases by using the inefficient variant as the "default" and adding a RULES pragma to get the efficient version. See, for example, the various IntXX to Int casts. We can use the same technique here.
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.
We know that the conversion interface can look like conv :: String -> IO [CChar] because the String marshalling routines that you proposed also don't have any additional information to convert a string. So, there must be a default conversion that doesn't get any further information from the user (in the conversion call). Otherwise, your marshalling routines wouldn't work either.
Since the string almost always needs to be translated before marshalling, it makes sense to provide combined variants anyway.
I am not necessarily against having combined variants as shorthands. The questions we are discussing is what should the primitives be. If we do it like I propose, the `Marshall' library doesn't have to know anything about Unicode. In you proposal, the marshalling library depends on the Unicode conversion library. It's merely a structural difference.
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.
What tool? I am not talking about a library plus tool, but only about the library. The high-level library should be part of the FFI standard and so will come included with every compiler that supports the FFI (just like the `List', `Maybe' and so on standard libraries). Cheers, Manuel