On Fri, Oct 08, 2010 at 07:33:54PM +0200, Daniel Peebles wrote:
I'm not sure I agree with the principle of least surprise here. Dealing correctly with text is hard and the text package presents a nice API for it. Surprise is good, here, I think: many developers out there don't even realize ASCII isn't good enough for text, and even the unicode-aware might not realize that indexing into text or case-insensitive matching are non-trivial operations. Forcing them to fix their code (through compilation errors) seems like a good idea, to me.
A new module, Data.Text.ListCrutch, could contain an exact duplicate of the Data.List functions with warnings attached to them warning (through deprecated pragmas?) users of the library that text is not simply a list of characters, and they should stop treating it as such.
I can see that as an argument for toLower and toUpper, but not the functions listed above, which all present a conceptual model as a sequence of Chars, just like all the functions that do have types that match the lists ones. It's not clear why it's useful to have filter with the same signature as lists and partitionBy different.