Haskell Libraries Wishlist
ijones at syntaxpolice.org
Sun Oct 17 21:35:05 EDT 2004
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
Manuel M T Chakravarty <chak at cse.unsw.edu.au> writes:
> (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.
I think a static page, maintained with someone with both ears to the
ground and a lot of interest and curiosity (did someone mention Shae?)
makes the most sense, except for the poor soul who has to run out
there and collect, collate, and maintain the information himself.
> (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
> (c) freshmeat.net
> (d) Develop a user-updateable database for haskell.org
> Pros: custom made; easy to edit, little work to keep entries up to
> Cons: Somebody has to implement it; it's been proposed before and not
This is my favorite solution, and I think it will eventually be done,
but I completely agree that we need something in the meantime. I'm
much more interested in finishing Cabal (the building & registering
part) before moving on to the rest of the Infrastructure (the listing
and distributing part).
> I am strongly against (a) and (d). Alternative (a) is bad, we know
> that. Alternative (d) is vapour-ware and we need something working
I won't discourage anyone from working on a (d)-type solution layered
on Cabal, except to the extent that Cabal is still in the alpha stage
and will likely change. Some people have been more interested in this
part than the building & registering part, and I would encourage them
to take a look at Cabal in the state it's in and maybe hack up some
prototype and tell me where Cabal needs to go in order to support the
listing & distributing part: http://www.haskell.org/cabal
> 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.
> 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.
Sounds good to me.
More information about the Libraries