Re: Haskell Platform Proposal: add the 'text' library

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. On Fri, Oct 8, 2010 at 5:42 PM, Daniel Fischer wrote:

On Friday 08 October 2010 17:16:20, Johan Tibell wrote:

...

On Fri, Oct 8, 2010 at 11:00 AM, Ross Paterson wrote:

...

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.

Given text's focus on subsequences rather than single elements these differences make sense to me after a quick first scan.

Sure. But at least with break and replicate there's the problem that the functions on lists are used a lot, so text's naming violates the principle of least surprise. (Not sure whether find is used a lot.)

So what's worse, having the good names for substring oriented things in text and surprise unsuspecting users when "break (== '\n') text" doesn't compile or having more cumbersome names for the substring oriented functions?

I think having break and replicate corresponding to the Prelude types is preferable, although within the text package the current names are darned nice.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries