Quoth "Bryan O'Sullivan"
In the case of the text library, it is often (but not always) competitive with bytestring, and I improve it when I can, especially when given test cases. My goal is for it to be the obvious choice on several fronts:
- Cleanliness of API, where it's already better, but could still improve - Performance, which is not quite where I want it (target: parity with, or better than, bytestring) - Quality, where text has slightly more test coverage than bytestring
That sounds great, and I'm looking forward to using Text in my application - at least, where I think it would help with respect to correctness. I can't imagine I would unpack all my data right off the socket, or disk, and use Text throughout my application, because I'm skeptical that unpacking megabytes of data from 8 to 16 bits can be done without noticeable impact on resources. I wouldn't imagine I would be filing a bug report on that, because it's a given - if I have a big data load, obviously I should be using ByteString. Am I confused about this? It's why I can't see Text ever being simply the obvious choice. [Char] will continue to be the obvious choice if you want a functional data type that supports pattern matching etc. ByteString will continue to be the obvious choice for big data loads. We'll have a three way choice between programming elegance, correctness and efficiency. If Haskell were more than just a research language, this might be its most prominent open sore, don't you think? Donn Cave, donn@avvanta.com