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 <daniel.is.fischer@web.de> wrote:
On Friday 08 October 2010 17:16:20, Johan Tibell wrote:
> On Fri, Oct 8, 2010 at 11:00 AM, Ross Paterson <ross@soi.city.ac.uk>
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