On Fri, Oct 08, 2010 at 01:23:28AM +0100, Duncan Coutts wrote:
If everyone else thinks that it's vital that the same name in text be element based then we do have a tricky question with naming. We do want the primary operations to be substring, not element, so we would have to come up with some naming convention that lets us have sensible names for the primary operations while still having (much less useful) element based ones.
More seriously, 5 of the names conflict with corresponding standard list functions. As far as I can see, the naming incompatibilities between the 3 packages are the following: text base bytestring type in text (or equivalent if absent) --------------------------------------------------------------------------- break - breakSubstring Text -> Text -> (Text, Text) breakBy break break (Char -> Bool) -> Text -> (Text, Text) breakEnd - - Text -> Text -> (Text, Text) - - breakEnd (Char -> Bool) -> Text -> (Text, Text) count - - Text -> Text -> Int - - count Char -> Text -> Int find - - Text -> Text -> [(Text, Text)] findBy find find (Char -> Bool) -> Text -> Maybe Char partitionBy partition - (Char -> Bool) -> Text -> (Text, Text) replicate - - Int -> Text -> Text - replicate replicate Int -> Char -> Text spanBy span span (Char -> Bool) -> Text -> (Text, Text) split - - Text -> Text -> [Text] - - split Char -> Text -> [Text] splitBy - splitWith (Char -> Bool) -> Text -> [Text] unfoldrN - - Int -> (a -> Maybe (Char, a)) -> a -> Text - - unfoldrN Int -> (a -> Maybe (Char, a)) -> a -> (Text, Maybe a) zipWith zipWith - (Char -> Char -> Char) -> Text -> Text -> Text - zipWith zipWith (Char -> Char -> a) -> Text -> Text -> [a] * The -By suffix has been used for predicate versions in 5 cases here, but not for filter and findIndex. * The find function has no connection with findBy. It ought to have a name that is the plural of the name of the break function.