On 24.04 16:31, John Meacham wrote:
On Sun, Apr 23, 2006 at 05:27:43PM +1000, Donald Bruce Stewart wrote:
Following discussion, I've tagged FPS 0.4, a candidate for the base library. Changes:
* Renamed to Data.ByteString(ByteString) * Improved documentation * Tweaks to build under ghc 6.6 * Added: getLine, getContents, putStr, putStrLn, zip, unzip, zipWith * Much faster: elemIndices, lineIndices, split, replicate * More automagic benchmarks and QuickCheck tests.
Can we get rid of every reference to 'Char' in the interface? a search and replace setting them to 'Word8' should do it. Casting between Word8 and Char is just very wrong. a Char based FastString can be built on top of it, but we want to be typesafe in any interface.
The Chars in the interface make it much more easy to use in production code. Should we also change the type of putStrLn to: putStrLn :: [Word8] -> IO () ? I think the name ByteString implies that it uses bytes and removing the Char functions does not help much. I am mostly using them to handle UTF8 data at the moment and it works quite well. In effect this would mean sprinkling all my code with fromIntegral. The name Latin1 is particularly bad since there are many other single byte encodings around. We could have a Data.ByteString with a Word8+Char interface and the module name telling us it is about bytes. Then we can have a Data.Encode.String.{UTF8,UTF16BE,UTF16LE,UTF32BE,UTF32LE,Latin{1,2,3...}} - Einar Karttunen