Data.ByteString candidate 3
Donald Bruce Stewart
dons at cse.unsw.edu.au
Tue Apr 25 07:12:55 EDT 2006
> > 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:
The code is in the darcs repo:
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.
More information about the Libraries