Data.ByteString candidate 3
ketil+haskell at ii.uib.no
Tue Apr 25 07:56:58 EDT 2006
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.
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
If I haven't seen further, it is by standing in the footprints of giants
More information about the Libraries