Re: Data.ByteString candidate 3

On Wed, 2006-04-26 at 18:35 +1000, Donald Bruce Stewart wrote:
> 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.

I don't understand the need for the Char8 layer. How are Char8 literals
different from Word8 literals? You couldn't use "string" or 's' either
way.

> 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.

Ok, fair enough.

Axel.