Haskell Libraries Wishlist

[Manuel M T Chakravarty]

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 <chak at cse.unsw.edu.au> 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