Haskell Platform Proposal: add the 'text' library

[Daniel Peebles]

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 at 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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20101008/42d4b0b9/attachment.html