Haskell Libraries Wishlist

Manuel M T Chakravarty chak at cse.unsw.edu.au
Wed Oct 20 09:08:03 EDT 2004

On Wed, 2004-10-20 at 01:22, Olaf Chitil wrote:
> I agree that using the Wiki is a sensible compromise.
> 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.)

> I agree with Manuel that first we need to make some changes to the Wiki 
> page before we can expect other people to make entries there. After that 
> is done, I'm happy to place a big forward link onto the libraries page 
> to the Wiki libraries page. Later the old page can go when all 
> information has been transferred.
> As Manuel says we should come up with a template and explain it on the 
> Wiki page. Each entry should certainly be short, not much more than the 
> current: name, URL, paragraph of description. For further information 
> there could optionally be a Wiki link to a library specific page. I 
> don't know what to do with all the version numbers on the current Wiki 
> page. Are they really up to date?
> The page needs to be broken into several pages, because it is hard to 
> edit a huge page with the Wiki editor. On the other hand the hierarchy 
> should not be too deep, requiring too many pages to select and load. 
> Basically I think we could use the existing top level of the hierarchy 
> of the libraries&tools page. Naturally, if we want to change this 
> hierarchy later, this will be more complicated.

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.

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.

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.

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.

* 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

* 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

- I think "Extended Haskell" entries should be under program
- 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.


* Toplevel index page with links to topics pages

* Separate topics pages for libraries and tools

* Topic as listed above

* Format of entries:

    <package name as hyperlink to further info>
      < ........
        one paragraph description
        ........ >
      <supported OSes>


More information about the Libraries mailing list