Haskell Libraries Wishlist
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Mon Oct 18 02:14:25 EDT 2004
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:
> > (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:
> > (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
> > 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.
More information about the Libraries