Data.ByteString candidate 3

[Donald Bruce Stewart]

dons:
> john:
> > 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.

Ok, here's what I've done:
    http://www.cse.unsw.edu.au/~dons/fps/new/

The code is in the darcs repo:
    http://www.cse.unsw.edu.au/~dons/fps.html

The code has been partioned into:
    Data.ByteString         a Word8 only layer. All functions are in terms of Word8
    Data.ByteString.Char    provides an ascii/byte-Char layer over the Word8 layer.

So essentially this is the Data.ByteString that John and Ashley were
looking for, I think, and with a new explicit Char layer, for people
like Simon, Einar and me, who need the convenience of literal Chars.

This separation means there is now an encoding-agnostic Word8 level of
high-performance code, which should be generally useful.

I'm quite happy with this now, the code is a lot cleaner, and hopefully
this will appease the people who disliked the intermingling of Char and
Word8 code, which I agree was unsatisfactory.

Opinions?

-- Don