On Mon, Aug 3, 2009 at 4:44 PM, Don Stewart
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