Haskell Libraries Wishlist

[Manuel M T Chakravarty]

On Mon, 2004-10-18 at 11:35, Isaac Jones wrote:
> I'm CC'ing John Peterson since he's one of the maintainers of the
> haskell.org/libraries page and he hasn't made an appearance in this
> discussion yet.
> 
> Manuel M T Chakravarty <chak at cse.unsw.edu.au> writes:
> 
> (snip)
> > (a) The current haskell.org/libraries/ page.
> >   Pros: we have got it
> >   Cons: developers cannot alter it themselves; we know it doesn't work
> 
> This begs the question of _why_ it doesn't work.  All developers, or
> anyone else, has to do is email the page maintainers and they are
> pretty responsive in getting stuff onto the page.  The fact that
> developers don't do this makes me think that the freshmeat solution
> (c) won't work.  Just a guess.

On freshmeat, entries are often not maintained by a developer, but a
user of a package.  I don't think a user would send an entry to the
Haskell page maintainers.

> > (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
> 
> This is indeed a nice solution, since Shae-type characters can edit
> the page and library authors can add their own stuff.  Other cons
> include temporary unavailability due to SPAM, and maybe some other
> trust issues wrt anyone being able to edit the pages.  I don't think
> those are very important, personally.  I might change my mind the
> first time I see a trojaned version of cabal or something appear
> there, and have someone claim that they downloaded it from an official
> Haskell site.

That's a wiki faq:

  http://c2.com/cgi/wiki?WhyWikiWorks

> > (c) freshmeat.net
> (snip)
> 
> > (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
> 
> This is my favorite solution, and I think it will eventually be done,
> but I completely agree that we need something in the meantime

If somebody every develops a better solution, let's use it.  Until then,
let's use what works today.

> > Besides (d) is going to need a maintainer and I think we can use
> > our time for better things.
> 
> If you see (d) as being a part of a package distribution architecture
> like CPAN, then I feel this is actually one of the most important
> things we could be working on right now.

A package distribution architecture would be great, but I think we are
still a fair bit away from that.  The original post in this thread shows
that today, it's hard to even find what's out there.

Manuel