Re: Haskell Libraries Wishlist

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 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