RE: Haskell Libraries Wishlist

With all that, there are two major issues here (ie, two sorts of users): (1) People looking for libraries and (2) people writing libraries. Re (1) - library users ~~~~~~ Currently the wiki page doesn't seem to be known widely. It would have to be prominently linked from the http://haskell.org/libraries/ In fact, I think we need to make a decision on which page we want to be The Haskell Libraries Page(TM). Two partly overlapping, partly inconsistent tables of libraries are just going to confuse people who search for libraries. I think, we have four alternatives: (a) The current haskell.org/libraries/ page. Pros: we have got it Cons: developers cannot alter it themselves; we know it doesn't work (b) The wiki page Pros: Easy to edit for everybody; exists already Cons: Developers need to use the wiki (not hard, but probably a hurdle for those who have never done it); free form style of wiki is more work to edit and a common format must be maintained by convention (c) freshmeat.net Pros: Easy to edit for everybody; exists already; very little work to keep entries up to date with all the formatting and layout being automatised Cons: Developers need to get a freshmeat account (not hard, but it needs to be done) (d) Develop a user-updateable database for haskell.org Pros: custom made; easy to edit, little work to keep entries up to date Cons: Somebody has to implement it; it's been proposed before and not done I am strongly against (a) and (d). Alternative (a) is bad, we know that. Alternative (d) is vapour-ware and we need something working now. Besides (d) is going to need a maintainer and I think we can use our time for better things. (Note that freshmeat entries are actually edited by the admin crew for grammar, style, and consistency. We'd never have the resources to do that effectively - ie, with the same turn around they got.) It is harder to decide between (b) and (c). In the interest of getting a result quickly, the wiki may be the better choice, as we already have got a page which just needs to be cleaned up. The wiki also makes it easy for people to add some documentation etc to libraries they provide. However, (c) has the advantage that it is browsed by non-Haskell people, too. So, if we have got a good library in some domain, non-Haskellers will find it in their freshmeat search and maybe become interested in Haskell. Moreover, freshmeat's layout and and data organisation is perfect for listing software packages, whereas with the wiki, we need to agree on some layout and maintain it. Personally, I would tend to go with the wiki as The Haskell Libraries Page, but encourage people (at least for larger projects) to add freshmeat entries, which are then linked from the wiki. Basically, we wiki would serve as an index into the freshmeat with the ability to easily provide additional annotation and documentation. Re (2) - library developers ~~~~~~ The story for developers is a much more complicated for all the reasons SimonM listed. I agree that we should move forward on the package infrastructure and Cabal. However, as this is certainly a longer term development, let's decouple it from the issue of how to provide an up-to-date library index to users. Summary ~~~~~~~ I propose to do the following: - Prominently advertise the wiki library page at http://haskell.org/libraries/ stating that we phase out the static page in favour of the wiki page. - Copy all useful information from the static page to the wiki. - Decide on a layout and page structure for the libraries on the wiki. (If we want to accommodate more libraries, we probably need some subdivision of the information etc.) - Encourage and set up freshmeat entries for at least larger projects and link them from the wiki. Cheers, Manuel On Wed, 2004-10-13 at 19:49, Simon Marlow wrote:

On 13 October 2004 02:18, Shae Matijs Erisson wrote:

...

Manuel M T Chakravarty writes:

...

How can this be solved? Somebody could sit down and build a system that supports author submission that get automatically processed etc. AFAIK that has been proposed before and nothing happened. So, I wonder why not reuse a resource that already exists, namely

This exists: http://www.haskell.org/hawiki/LibrariesAndTools

...

Freshmeat entries need not necessarily be created and updated by the authors of some software. Instead, interested users can maintain a freshmeat entry. This facility seems to improve the accuracy of the freshmeat db.

freshmeat seems like a good idea too.

I'd just like to say something about the direction I think we want to be headed here. As our package infrastructure and Cabal (http://www.haskell.org/libraryInfrastructure/) become more mature, we should aim to base our library story around Packages. This way we get a consistent view of libraries, with a consistent set of tools to build, install and manage them.

So what's still needed for this to happen? Well, I'm planning to support more of the Package proposal in GHC 6.4 (package versioning, exposed/unexposed packages & modules, per-user package configuration etc.). We also need more people to package their libraries using Cabal, try to find areas of weakness and help fix them.

Finally, we need one place to list Packages. The LibrarisAndTools page in the Wiki is a good start, but it needs to transition to be more Package-centric. Just starting a new section for Cabal packages would be a good idea for now.

We need to provide easily accessible answers to questions that prospective library contributors have:

- what package name can I use? (short answer: choose one that isn't used yet).

- what module names can I use?

- what guidelines are there for designing library interfaces?

We have various half-baked or out of date answers to these questions, but it's probably about time we revised the story and made it more prominent. Hmm, I think I just talked myself into tackling this.

Cheers, Simon