Haskell Libraries Wishlist

[Olaf Chitil]

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