[Haskell-cafe] Re: Thinking about what's missing in our library coverage

[Alexander Dunlap]

On Mon, Aug 3, 2009 at 4:44 PM, Don Stewart<dons at galois.com> wrote:
>
> Following Simon M's advice, I look over the typical "batteries"
> categories, using Python as input:
>
>    http://docs.python.org/library/index.html
>
> The following things were missing from the current Platform. There are many.
> How would you identify the top, say, 5 libs to add?
>
> -- Don
>
>
>    * String support
>          o pcre regexes [pcre-light] [regex-pcre] — what’s our best regex lib?

For something like this, it seems like all of the regex libs probably
have pros and cons. It would be good if we could identify what these
are and create a library that was the "best of all worlds" instead of
just picking one and going with it.

>          o unicode text [text] [text-icu] — packed, unicode text

This is essential, although I don't know if it is stable enough for
the platform (?).

>    * text
>          o pandoc — markdown, reStructuredText, HTML, LaTeX, ConTeXt, Docbook, OpenDocument, ODT, RTF, MediaWiki, groff

No. Pandoc is too actively developed to go into the HP. It's also much
more of an end-user application than a "standard library" - it's
applications are not general enough to be included in the standard
distribution.

>    * math and numerics
>          o blas — BLAS
>          o cmath — C math functions
>          o dimensional — physical dimensions
>          o fftw
>          o mersenne-random — fast randoms

The interfaces here should be unified more to create a general Haskell
numerical library, IMO.

>    * compression
>          o bzip2
>          o zip
>          o tar

Definitely.

>    * file formats
>          o config parser

This would be quite useful.

>    * crypto
>          o hmac, md5, sha, hashing

Yes.

>    * systems
>          o getopt
>          o logging
>          o termio
>          o editline
>          o mmap

All of these, at some point.

>    * Internet
>          o network-bytestring
>          o ssl
>          o json
>          o feed (rss, atom)
>          o mime
>          o base64 et al
>          o uuencode
>          o cgi
>          o fastcgi
>          o urls
>          o ftp, http, imap, smtp clients
>          o uuid
>          o url parsing
>          o http server
>          o xml-rpc

Interface unification would help. Especially network-bytestring seems
to be too ad-hoc for me - it would probably be better to put
ByteString support into the regular Network library....

>    * Internationalization
>          o gettext
>          o locale
>          o i18n

Yes, although again, maturity?

>    * Development
>          o hscolour

Yes.

My main concern is with libraries like attoparsec and
network-bytestring - these libraries seem to be somewhat ad-hoc
conversion of traditional libraries to use ByteStrings. We should come
up with a cleaner, more elegant way of dealing with the
String/Text/Strict ByteString/Lazy ByteSTring gap, as most libraries
that apply to one of those types also apply to the other two, as the
first two and last two especially and more generally all four
essentially represent the same thing. We shouldn't bless libraries
that don't have a good way of applying equally to these three.

A possible solution could be a standardized package-common,
package-string, package-text, package-bytestring,
package-lazybytestring naming convention, or a Category.Module,
Category.Module.String, Category.Module.ByteString.Strict,
Category.Module.ByteString.Lazy, Category.Module.Text convention. We
could also work something up with type classes. I just don't like how
a lot of libraries implement support for various string types just
based on need rather than creating a clean, comprehensive interface.

Alex