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