Manuel M. T. Chakravarty
chak at cse.unsw.edu.au
Mon Dec 4 01:17:09 EST 2000
qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,
> 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.
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
> 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).
More information about the FFI