Summary and call for discussion on text proposal
malcolm.wallace at me.com
Sun Nov 7 11:56:50 EST 2010
> Option 1 (current Text lib design)
> break :: Text -> Text -> (Text, Text)
> breakBy :: (Char -> Bool) -> Text -> (Text, Text)
> This gives the short name 'break' to the substring version, and the
> longer name 'breakBy' to the character predicate version.
I very much dislike this option, for the reasons already rehearsed.
And Ian presented some evidence that there are no (or very few) usages
of the short name versions in client libraries on hackage. But this
raw data does not give us enough context to know how to interpret it.
Are there simply very few clients of the Text package at all so far?
Are there many clients but they use other parts of the API? How many
usages of the long name versions appear? And that does not address
the idea that perhaps the clients indeed ought to be using the
substring versions, but for whatever reason have not done so.
> Option 2
> breakSubstring :: Text -> Text -> (Text, Text)
> break :: (Char -> Bool) -> Text -> (Text, Text)
> This gives the short name 'break' to the character predicate version
> and the longer 'breakSubstring' to the substring version.
This option would be preferable to option 1, although I understand it
is not likely to win the author/maintainer's vote. Of course,
'breakSubstring' is a slightly extreme version of the name, to make a
point. It could just as easily be 'breakStr'.
> Option 3
> breakStr :: Text -> Text -> (Text, Text)
> breakChr :: (Char -> Bool) -> Text -> (Text, Text)
> This give neither version the short name 'break', but gives both
> reasonably short names with a suffix to indicate the character
> predicate vs substring.
As a compromise between options 1 & 2, this option has merit. It
leaves open the possibility that the signatures of the short names
might yet be decided at a later date. If Bryan were willing to go
with this option, I would certainly support it.
More information about the Libraries