Data.ByteString candidate 3

[Donald Bruce Stewart]

A.Simon:
> different, but still, I propose to
> 
> - have a library that deals with packed strings of 32-bit Haskell Char
> - have a library that deals with packed Word8 sequences
> 
> This way, it will hurt if you touch the bare-metal Word8 representation,
> but then, using Word8 sequences is quite an optimisation that you don't
> use when you start developing an application. A simplistic solution like
> this avoids the whole discussion on whether there should be an Ord or
> toUpper for Latin1, or how to coerce a packed Latin1 string to a packed
> Word8 representation.

I'd like to say that all I want to do is have the Word8 "bare metal" 
layer, and a minimal Char8 layer layer on top (where all conversions are
equivalent to id) to make the fast layer usable for speed-is-everything
projects. If we don't add the Char8 layer, the projects will end up 
having to write their own anyway, since Word8 literals are unbearable.

This is what's currently implemented. 

I'm providing the 2nd part of your plan above, with a little sugar for
people like me and Einar who need it. The first part, 32-bit packed
haskell strings, is another piece of work.

I'm not sure we need 5 kinds of Foo-encoding layers, and I don't plan to
write them.

-- Don