FPS/Data.ByteString candidate

[Einar Karttunen]

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