Re[2]: [GHC] #710: library reorganisation

Hello Ketil, Friday, April 28, 2006, 10:52:17 AM, you wrote:

Bulat Ziganshin writes:

...

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

What would be required for it to replace PackedString? (If that is a goal?) If I understand correctly, PS is an array of Word32, and ByteString is (obviously) an array of Word8. Would it be sufficient if there was a 'Char' interface supporting all of Unicode (the obvious candidate encoding being UTF-8), or must it support UCS-2 and UCS-4 directly?

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. it may be ucs4, utf8, or even ByteString+String (that selects representation depending on presence of non-Latin1 characters in string) support of specific encodings, such as utf16 or ucs4, will be great for special purposes (as i said, ucs4 allows fastest processing with support for full Unicode range, while utf16 is great for working directly with windows filenames), but that is another question. i just want to point that omitting PackedString may create problems for the people that use it one more suggestion about standardizing modules: ByteString gives access to Word8 strings and it provides ability to work with memory regions directly PackedString should just allow to work with some compact String representation without any information about it's internal representation, so it can be implemented using any above-given approach PackedString.UTF8 should work with memory areas that contains UTF8-packed strings and give direct access to such memory areas PackedString.UTF16 should work with memory areas that contains UTF16-packed strings and, again, give direct access to such memory areas The same for PackedString.UCS4... So, PackedString implementation should just import one of these modules and then rexxport only functions that are representation-independent. If someone just wants fast and compact strings, he should import this module, if he want some specific representation, he should import representation-specific module -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com