Data.ByteString candidate 3

[Ketil Malde]

dons at cse.unsw.edu.au (Donald Bruce Stewart) writes:

I already voiced this on IRC, but if you'll forgive me, I'll sum up my
small minority report.

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

I'm very happy with the separation, and I think using the Latin-1
charset as the default is the right choice.  The only thing I am
unhappy about, is the last minute name change, which means that the
interpretation as Latin-1 is no longer explicit to the user.

A naive user may think that the anonymously named Char module
interprets the locale for instance, or might disregard the character
set issues entirely, and be confused when a string literal using
characters with code points > 255 don't work as expected.

In addition, it is natural to extend this with other character sets,
but it is no longer obvious where to put sibling modules implementing
the same Char functionality with a different (single byte) encoding.

Quite frankly, I don't see any advantage of selecting one particular
encoding, and then disguise the fact from the user.

> Opinions?

Well, you did ask.  Thanks for the good work, I'm currently
benchmarking my programs to check what the current Char IO costs are,
and if my suspicions are corroborated, I'll spend some time this week
to switch. 

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants