On Thu, 2004-10-21 at 00:21, Olaf Chitil wrote:
My comments on Manuel's proposal:
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.
I am not entirely convinced, but given that you have got previous experience with categorising these packages, let's just go with the combined approach as on haskell.org/libraries/ today.
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.
Language level is certainly a good parameter. Let's make the <supported OSes> field into a prerequisites or <supported platforms> field listing OSes, Haskell systems, and used language extensions. I don't agree entirely on the license bit, though. I am happy to list libraries that don't have a license, but nobody in their right mind would use them for any serious development, which makes them less than useful. Anyway, instead of getting into a license discussion, let's just say that we list the license if known or otherwise add the phrase "license unknown". Users can then decide whether they care or not.
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.
If there is both, I would make the name of the package into a link to the wiki page and put the text "(website)" next to the page name with a link to the external page (the wiki will additionally put an icon next to the link indicating it is external).
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.
Integrating tools and libraries, let's start with the following index
(which is a variant on the current haskell.org/libraries/ index):
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
- Preprocessors
- Libraries
* Web programming, HTML, XML
* Data structures
* Databases
* Graphics and graphical user interfaces
- Widget sets
- Graphics
- Graphics file formats
* Pretty printing
* Music
* Mathematics and numerics
* Hardware verification
* Robots
* Misc
* Library collections
New Summary
~~~~~~~~~~~
* Toplevel index page with links to topics pages
* One page per topic as listed above
* Format of entries:
<package name as hyperlink to further info> <optional external website>
< ........
one paragraph description
........ >