
My comments on Manuel's proposal:
I do not quite see why more people would be willing to edit a Wiki page than send an email to John and me, but it is worth trying. To make this clear: John and I are perfectly able to handle the incoming emails about desired additions and changes to the pages; there simply are very few of them. Most entries actually are written by ourselves, just from coming across things on the various Haskell mailing lists or otherwise. This activity is too time consuming (especially writing short descriptions when it is unclear to me what the library actually does) and I only do it occasionally.
I think the later is one reason why the wiki might work better. The wiki enables everybody interested to clean up other people libraries' entries. You might ask why should anybody do this? Firstly, freshmeat does work partially because package author and freshmeat entry maintainer need not be the same person. Secondly, what happens with wikis often is that people who use the wiki to try to find some information and are not successful do update the wiki if they find this information by other means. (The occasional wiki user probably won't do that, but regular users tend to develop a sense of responsibility for the accuracy of the information.)
Package author and the person sending John and me an email don't need to be the same person either... However, no point going on about this issue, let's go wiki.
Let me make a concrete proposal for a structure for the wiki and see whether we can evolve this into something everybody can agree on.
Libraries & tools ~~~~~~~~~~~~~~~~~ I think we should have two separate pages for libraries and tools. These days there are just too many of both, so that the main effect of treating them together is longer, less clear pages. Having said that, we might have a top-level page which is essentially only an index for both together, but then that should point to separate pages for, eg, FFI tools and FFI libraries.
There had been a separate page for libraries and another one for tools for some time. John and I finally merged the two pages, because the division proved to be hard and artificial. For many tasks there exist both libraries and tools. E.g. Hood is a library for debugging, Hat is a tool. Parser combinators are in a library, Happy is a tool. So you would have mostly the same categories in both the tools and the libraries part. Usually you search for something to solve your problem and you care less if it is a library or a tool. Also many tools comprise some libraries. E.g. QuickCheck is mostly a library. Hence I think the division is unnatural for Haskell that claims embedded domain specific languages as major application area. It is hard enough sometimes to distinguish between libraries&tools and applications.
Short descriptions versus table of OS/versions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Currently, haskell.org/libraries/ and hawiki differ as follows: The former lists the name of each package with a hyperlink to that packages web sire followed by a one paragraph description. In contrast, the wiki has a table listing versions on different OSes. I think we want to preserve the one paragraph description of haskell.org/libraries/, but add some of the information of the table on the wiki. I agree with Olaf that it is probably hard to keep the version numbers up to date, but what I find very useful is to have a list of the supported OSes and also the license information that the wiki provides.
Many authors of small libraries have probably never thought of the license. So they should probably not be forced to list one, but it is a good option. For libraries the required language level (Haskell 98, ghc extensions, ghc&Hugs,...) might be more relevant than the OS.
The hyperlink at the package name can either be a directly link to the package web page or a link to a wiki page with more information including a link to the package web page.
Fine, although there might be a web link to the official package page and a Wiki link to a comments-by-the-user page.
Page structure ~~~~~~~~~~~~~~ I think we should have one wiki page for each of the following topics, separating tools and libraries (modelled after haskell.org/libraries/). More precisely, one wiki page for each "*" bullet point, which is turn is structured as indicated by the "-" points.
Tools: * Program development - Compiler and compilation tools - Integrated Development Environments - Editor support - Source documentation and browsing - Testing - Tracing and debugging - Type setting - Misc * Foreign language interfacing * Web programming
Libraries: * Data structures * Foreign language interfacing * Databases * Graphics and graphical user interfaces - Widget sets - Graphics - Graphics file formats * Web programming, HTML, XML * Pretty printing * Music * Mathematics and numerics * Hardware verification * Robots * Misc * Library collections
Remarks: - I think "Extended Haskell" entries should be under program development.
Not sure, but I agree that "Extended Haskell" is not good.
- I don't like "Interfaces to specific systems" as something like hMPI is arguably for parallel programming and all the GUI libraries are arguably also interfaces to specific systems. For similar reasons "Interfaces to databases" should be under databases.
Fine.
Summary ~~~~~~~
* Toplevel index page with links to topics pages
Yes.
* Separate topics pages for libraries and tools
No.
* Topic as listed above
Ok.
* Format of entries:
<package name as hyperlink to further info> < ........ one paragraph description ........ >
<supported OSes>
and/or required Haskell language level / compiler
<license>
Ciao, Olaf