On Mon, Oct 11, 2010 at 1:12 PM, Malcolm Wallace
I have myself in the past implemented a Text-like library as a replacement for the standard list-of-char representation. (Before you ask, it is not publically releasable.) The basic decision I took there was that the Char type does not exist - the only thing available is Text. Another way of saying this, is that Char is simply the subset of all the Texts of size 1. I am not suggesting that the Prelude or ByteString should take this view, but if you proceed to look at the type signatures of the Data.Text package on the basis that Char/Text are the "same" thing, then it may become clearer how to resolve the apparent name/type clashes below.
Thanks, Malcolm. I do like this principle, and I'm comfortable with its implied further divergence from list/bytestring. The breakSubstring functionality is semantically:
breakSubstring x = break (==x) although there may be a more efficient implementation. Proposal: rename Text.break to Text.breakSubstring, and Text.breakBy to Text.break.
So far, I've been proceeding on the basis that I'd like naming to be consistent and descriptive, and to have more commonly used functions get shorter names than their less commonly used (but possibly more general) cousins. For instance, breakSubstring is descriptive, and it's consistent with bytestring, but it's much longer than break, even though breaking on a fixed string is more common. In this case, length and frequency of use trump the other considerations in my mind.
breakEnd - - Text -> Text -> (Text, Text)
- - breakEnd (Char -> Bool) -> Text -> (Text, Text)
breakEnd - breakEnd (Text -> Bool) -> Text -> (Text, Text)
Proposal: slightly generalise the type of Text.breakEnd.
I think that these generalisations are good ideas. Can someone else please weigh in, preferably the original authors of the H-P inclusion draft (Don, Johan)? findBy find find (Char -> Bool) -> Text -> Maybe Char
find find find (Text -> Bool) -> Text -> Maybe Text
Proposal: rename Text.findBy to Text.find.
I agree with the change of type, not so much with the naming. That's roughly my stance in the other cases, too.
I hope this is a useful contribution, if only to spark other ideas for how to resolve the impasse.
Definitely, thank you.