qforeign-0.62

[Marcin 'Qrczak' Kowalczyk]

Mon, 04 Dec 2000 17:17:09 +1100, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> pisze:

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

We can, but it will work only in some cases. It will not work
when somebody writes a function which accepts any conversion and
applies this function to a conversion where an optimization would be
preferable, unless he is very lucky in inlining and writes only code
where the conversion can be resolved statically.

> We know that the conversion interface can look like
> 
>   conv :: String -> IO [CChar]

In this case _any_ optimization making use of the representation of
particular conversions must use RULES (which is non-portable BTW).

An important application of such optimization is I/O. We don't want to
read the file contents into char[] buffers, convert them to [CChar]
only to put them back into char[] buffers to call iconv and finally
read back a String. The first buffer was already a good input to
iconv. Since a conversion will happen by default, it should not be
unnecessarily slow.

If the representation of some conversions makes the fact that they
work best on raw C arrays explicit, calling code will be efficient
no matter what was inlined and how dynamic is the place where the
conversion was specified.

I'm afraid that most of the time RULES will not fire and Haskell will
be yet slower than it is now. I don't want to force people to use
non-standard string representations to get reasonable performance
if the situation could be significantly improved by using explicit
representation of conversions implemented in C.

It should not be surprising that code which needs to convert between
Haskell strings and C strings (or Haskell strings and streams of bytes
in files) is dependent on a library which deals with these conversions.
Unfortunately the library cannot work well enough if the interface
is as simple as String -> IO [CChar]. I like making things simple
but here I cannot imagine how do do it without compromising efficiency.

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

OK, so what should this library provide? My functions were a step in
this direction, even if they were not explicitly marked as a part of
a high level library proposal.

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