Bulat Ziganshin writes:

IMHO, because PackedString is anyway abstract and DON'T support any way to see it's internal representation, any implementation that supports full unicode range, would be enough.

Perhaps I'm misrepresenting FPS here, but from my POV, the representation is very much the issue. I see the typical use for FPS to be a case where you have some data (files, network buffers, whatever), which is, essentially, a string of bytes. The Char interface(s) to FPS is, in theory, encoding agnostic, but in practice, it will be limited by the underlying encoding. IMO, that is okay, as long as the interesting encodings are supported. Note that ByteString.UTF8 is *not* going to be a replacement for the other encoding-specific modules, since that would mean you would have to do an (expensive) conversion of non-UTF8 data. The current scheme allows you to work with a universal Unicode interface (based on Char), but keeping the data in its 'native' representation. The question is how to extend this to muliti-byte fixed encodings (UCS-2 and UCS-4), and variable encodings (UTF-8, UTF-16, UTF-32, Shift-JIS, and why not Quoted-Printable?). I feel confident it can be done, but it is likely to involve some policy decisions and trade offs. -k PS: I implemented another single-byte encoding, Windows-1252. This builds everything from a charset table, and while currently not too efficient, should make it very easy to add other single-byte encodings. As usual: darcs get http://www.ii.uib.no/~ketil/src/fps-i18n -- If I haven't seen further, it is by standing in the footprints of giants

Hello Simon, Friday, April 28, 2006, 1:34:05 PM, you wrote:

Bulat Ziganshin wrote:

...

sorry for repetition, but ByteString library in its current state still don't replaces PackedString in functionality, because it don't support full Unicode range of chars

That's true, but frankly the current Data.PackedString is subsumed by [Char], so there's no good reason to keep it. I'll stop saying that Data.ByteString is replacing Data.PackedString to avoid confusion.

this module may be used by someone, though... as i already said, you can with the same success omit any other modules that is also not replaced by ByteString - what is the difference?

Would you like to write a Data.ByteString.UTF8 to fill the gap?

no, at least now. btw, i have my own private simple module that is called UTF8Z because it don't store length but uses 0 byte at the end of string. but this module omits any functionality except for pack/unpack. on the other side, it's representation is most compact among the all modules i've seen -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com