I understand that viewpoint, and it is a perfectly reasonable scope to choose. I was simply pointing out that it has kept me from being able to use Text for a number of applications. =)
An example of something I do with fingertrees of bytestrings that I can't do with text can be found in the second set of slides here:
http://comonad.com/reader/2009/iteratees-parsec-and-monoid/When playing with iteratees when you need more input it glues together the buffer onto the end of the existing buffer. If your buffer is a bytestring (or text) that can be pretty painful due to the O(n) append, and potentially large amount of read ahead in certain classes of parsers. Even if you go to lazy bytestrings/text, its kind of a crappy solution, because you are consistently appending the buffers on the wrong end of the list, so the asymptotics suffer.
To that end, I would up using a variant on an iteratee which instead of directly concatenating, stored the bytestring fragments in a fingertree (or skew binary random acccess list). This fixed the asymptotics on long look ahead, in exchange for bloating my memory footprint and killing the space usage guarantees provided by Oleg's iteratees.
So now I have a fingertree of buffers (be them bytestrings or text) being held on to by my iteratee. I can choose to retain all of the buffers read (rather than just the unparsed 'right hand side') in the fingertree. This lets me backtrack. Now I can implement a parsec parser where the current 'input' is just a cursor location -- an offset into the fingertree of buffers.
This means that parsec's built-in try functionality works, and that I can run a parsec parser 'online'. The most common operation is to read the next character from _some_ index/input, but it doesn't always just drop a character as it goes. Futhermore, I have these cursors as meaningful references into the input buffer. I can say a lot about them.
I can slice between two cursors from the same set of buffers and I can even know if they came from the same bytestring/text fragment based on the index and where each fragment starts and ends, and if so, no copying is involved at all. Since this is happening inside of a monad (Parsec), there could be a bunch of these cursors alive at any point. My memory usage dropped off _dramatically_ when I made this improvement.
There doesn't exist a good equivalent under the API that I have available to me in Text, and I don't have the ability to build one over the exposed API. I can implement the common 'parsec' input pattern, but not invert control of it using the iteratee machinery to let me run it on-line, not without walking backwards and forwards over the same bits of Text repeatedly and doing all sorts of manual tracking that blows up my asymptotics.
Do I believe that the Text API should expose this kind of functionality? I'd hazard not. In the above, each of my cursor positions is well formed, it always
comes between two characters. Any slice made between any two valid
cursors for the buffer set succeeds. To provide those guarantees you need rank 2 types and general scariness that does not belong in a Platform library.
However, my first attempt at implementing this WAS on top of the Text API, until I ran into a situation where the design goal of encapsulation forced me to a full stop, and required me to go back and re-engineer on top of ByteString. ByteString has a very similar API, but is at least currently willing to expose an Internal module as a dodge.
I realize there is a desire from a library encapsulation perspective to hide the internals, to make them easier to change, and to make it so the public facade isn't so brittle. I simply wish to point out that there is a cost for such abstraction. Namely that people who would otherwise happily be using a library and singing its praises can be completely locked out of it.