qforeign-0.62

[Manuel M. T. Chakravarty]

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