RE: Haskell Libraries Wishlist

newer
Generic I/O

older
RE: Preprocessors

Simon Marlow

13 Oct 2004 13 Oct '04

5:49 a.m.

On 13 October 2004 02:18, Shae Matijs Erisson wrote:

...

Manuel M T Chakravarty 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

Show replies by date

Isaac Jones

17 Oct 17 Oct

6:53 p.m.

New subject: Haskell Libraries Wishlist

"Simon Marlow" writes:

...

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.

By the way, my random idea for a libraries database would be to have the database updated by uploading Cabal description files which include information about the package name, version numbers, modules contained, compatibility, etc. So whenever someone packaged up their library, they would upload the description file to the server. Maybe they'd upload the package itself too, but that's another story. peace, isaac

Manuel M T Chakravarty

9:04 p.m.

New subject: Haskell Libraries Wishlist

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

Isaac Jones

9:35 p.m.

New subject: Haskell Libraries Wishlist

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. 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 Haskell site.

...

(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. 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 now.

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. (snip)

...

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. peace, isaac

Manuel M T Chakravarty

18 Oct 18 Oct

2:14 a.m.

New subject: 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

Graham Klyne

4:54 a.m.

New subject: Haskell Libraries Wishlist

At 21:35 17/10/04 -0400, Isaac Jones wrote:

...

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

Hmmm... I wasn't really aware of this (though it's stated clearly enough if I actually read the page), which may be part of why "developers don't do this". Also, libraries tend to start out tentative, and evolve to something that we'd be happy to see offered as an "official" library. (I recognize that designation is not quite right, but I think there's a sense of having a community imprimatur for libraries listed at http://www.haskell.org/libraries/ .) Which leads me to the idea that a well-publicized Wiki for individual submissions linked to (say) an email or RSS feed that alerts the library page maintainer(s) who make a judgement whether or not a library is ready for more substantial acknowledgement. I suppose it's like the difference between a personal rambling and a peer-reviewed paper?

...

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.

I think the advantage of starting with a Wiki is: (1) it creates a natural collecting point for candidate libraries, without forcing the need for one person to track them down, and (2) it proviodes the page maintainer with some developer-supplied text to work with. ... As a random developer, I find it's easy to overlook the community administration aspects that actually make things happen. To the extent that the Haskell community really benefits from the development of new library code, maybe a link on the Haskell.org home page for library developers, setting out their options for publicizing their work. ... In writing the above, I've ignored the role of Cabal, which I'm sure will be important. A simple case, 1-page howto create a simple Cabal package might help here (the proposal is a little bit daunting for a developer in a rush). At some stage I plan to try and package some of my work with Cabal, and might just have a go at doing just that (assuming noone else has beaten me to it). #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

Shae Matijs Erisson

7:12 a.m.

New subject: Haskell Libraries Wishlist

Manuel M T Chakravarty 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 (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 (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

What about a compromise like: Library and application authors put the Cabal file for their lib or app on the wiki, and add CategoryLibrary or CategoryApplication to the bottom of their page so that another program can suck those Cabal descriptions out of the wiki and into a user-friendly sexy-looking database? Then you have a standard format (cabal), user updates (wiki), and the nice search and display that something like WASH or Halipeto plus HaskellDB can give you, all without manual intervention by a 'libraries admin'. -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby

Peter Simons

7:26 a.m.

New subject: Haskell Libraries Wishlist

Shae Matijs Erisson writes:

...

Library and application authors put the Cabal file for their lib or app on the wiki [...]

I'd prefer if the application authors put an URL to the Cabal file into the wiki. Then I'd have to update it only on my own site (which I update anyway when I make a new release), but the wiki would be "up-to-date" nonetheless. Having to edit the wiki pages is something I'd like to avoid, if possible. Peter

Shae Matijs Erisson

7:11 p.m.

New subject: Haskell Libraries Wishlist

Shae Matijs Erisson writes:

...

Then you have a standard format (cabal), user updates (wiki), and the nice search and display that something like WASH or Halipeto plus HaskellDB can give you, all without manual intervention by a 'libraries admin'.

Speaking of which, here's a partial prototype (using HaskellDB and Halipeto) written by David Himmelstrup: http://www.scannedinavian.org/cgi-bin/web/webbih It takes uploads in the Cabal.description format, where the fields: ["Homepage","Name","Category","Description"] are required. -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby

John Peterson

9:36 p.m.

New subject: Haskell Libraries Wishlist

Sorry to be so unresponsive on this. Here's an "official statement" from your haskell.org guy: a) There's no way Olaf and I can keep up with any very dynamic information on libraries. The current haskell.org setup is as good as it's going to get (occasional nagging emails to throw a few lines of html on the page) b) The wiki is a GOOD THING! I would be happy to so something simple like redirect every library through a wiki page in hwiki so there would be a more uniform treatment of libraries. c) Organization is a GOOD THING. The wiki isn't enough to keep things organized. Anyone that wants to install stuff to make library web pages more organized will get an admin account on haskell.org d) I rather like having things under the haskell.org roof - delegating to a separate website is perhaps a bad idea. But on the other hand we don't have anything on haskell.org at the moment that would replicate the functionality of other sites. Wish I had more time to help with this kind of stuff --- John

Ketil Malde

19 Oct 19 Oct

3:20 a.m.

New subject: Haskell Libraries Wishlist

John Peterson writes:

...

d) I rather like having things under the haskell.org roof - delegating to a separate website is perhaps a bad idea.

haskell.org as in the same publishing system, the specific machine, or the domain? The latter is easy to amend by e.g. defining wiki.haskell.org in DNS, and perhaps adding a redirect from http://haskell.org/wiki -kzm -- If I haven't seen further, it is by standing in the footprints of giants

Manuel M T Chakravarty

18 Oct 18 Oct

9:03 p.m.

New subject: Haskell Libraries Wishlist

On Mon, 2004-10-18 at 21:12, Shae Matijs Erisson wrote:

...

Manuel M T Chakravarty 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 (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 (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

What about a compromise like: Library and application authors put the Cabal file for their lib or app on the wiki, and add CategoryLibrary or CategoryApplication to the bottom of their page so that another program can suck those Cabal descriptions out of the wiki and into a user-friendly sexy-looking database?

Then you have a standard format (cabal), user updates (wiki), and the nice search and display that something like WASH or Halipeto plus HaskellDB can give you, all without manual intervention by a 'libraries admin'.

Sure. Sucking information of the wiki once the Cabal infrastructure can make use of it or there is some DB backend that supports flexible searching is perfectly fine. Nevertheless, we need to start with the wiki. Cheers, Manuel

Isaac Jones

11:06 p.m.

New subject: Haskell Libraries Wishlist

Manuel M T Chakravarty writes: (snip)

...

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.

I feel like there is a consensus, especially now that John has weighed in, that we probably want to transition to the wiki. Can we have a prominent link added from the libraries page, and once the wiki has all the information that the libraries page has now, we can change it to a redirect? John? Are there other action items and volunteers to make the wiki more usable for this? John Said:

...

c) Organization is a GOOD THING. The wiki isn't enough to keep things organized. Anyone that wants to install stuff to make library web pages more organized will get an admin account on haskell.org

We could wait to see if an organization will emerge from the wiki, and I encourage someone to start to move the content over... It could also be broken up into more than one page if the current wiki structure doesn't work for some reason. I, personally am not wedded to the layout of the wiki page, fwiw. Shae Said:

...

Speaking of which, here's a partial prototype (using HaskellDB and Halipeto) written by David Himmelstrup: http://www.scannedinavian.org/cgi-bin/web/webbih

I think this is super cool, and will do my very best to continue to push Cabal in a direction that supports this kind of work. Personally, I think we should use the wiki in the mean time, and wait for something like David's work to mature. By the way, I propose that the name for a CPAN-type system be "Hackage" since it starts with an "H", sounds like "Package" and has the word "hack" in it. I think Alexander Jacobson came up with this word, and has given me permission to steal it :) peace, isaac

Manuel M T Chakravarty

19 Oct 19 Oct

3:55 a.m.

New subject: Haskell Libraries Wishlist

On Tue, 2004-10-19 at 13:06, Isaac Jones wrote:

...

...
c) Organization is a GOOD THING. The wiki isn't enough to keep things organized. Anyone that wants to install stuff to make library web pages more organized will get an admin account on haskell.org

We could wait to see if an organization will emerge from the wiki, and I encourage someone to start to move the content over... It could also be broken up into more than one page if the current wiki structure doesn't work for some reason. I, personally am not wedded to the layout of the wiki page, fwiw.

I think we should come up with a template of what information we would like to be available in the wiki. We might start from the format currently used on the wiki and the information that's supposed to be in Cabal descriptions. Manuel

Olaf Chitil

11:22 a.m.

New subject: Haskell Libraries Wishlist

Manuel M T Chakravarty wrote:

...

...
We could wait to see if an organization will emerge from the wiki, and I encourage someone to start to move the content over... It could also be broken up into more than one page if the current wiki structure doesn't work for some reason. I, personally am not wedded to the layout of the wiki page, fwiw.

I think we should come up with a template of what information we would like to be available in the wiki. We might start from the format currently used on the wiki and the information that's supposed to be in Cabal descriptions.

I agree that using the Wiki is a sensible compromise. I do not quite see why more people would be willing to edit a Wiki page than send an email to John and me, but it is worth trying. To make this clear: John and I are perfectly able to handle the incoming emails about desired additions and changes to the pages; there simply are very few of them. Most entries actually are written by ourselves, just from coming across things on the various Haskell mailing lists or otherwise. This activity is too time consuming (especially writing short descriptions when it is unclear to me what the library actually does) and I only do it occasionally. I agree with Manuel that first we need to make some changes to the Wiki page before we can expect other people to make entries there. After that is done, I'm happy to place a big forward link onto the libraries page to the Wiki libraries page. Later the old page can go when all information has been transferred. As Manuel says we should come up with a template and explain it on the Wiki page. Each entry should certainly be short, not much more than the current: name, URL, paragraph of description. For further information there could optionally be a Wiki link to a library specific page. I don't know what to do with all the version numbers on the current Wiki page. Are they really up to date? The page needs to be broken into several pages, because it is hard to edit a huge page with the Wiki editor. On the other hand the hierarchy should not be too deep, requiring too many pages to select and load. Basically I think we could use the existing top level of the hierarchy of the libraries&tools page. Naturally, if we want to change this hierarchy later, this will be more complicated. In principle everything said about the libraries&tools page is also valid for the applications page and the bookshelf. But we should certainly first do one. Ciao, Olaf

Isaac Jones

1:25 p.m.

New subject: Haskell Libraries Wishlist

Olaf Chitil writes: (snip)

...

I agree that using the Wiki is a sensible compromise.

I do not quite see why more people would be willing to edit a Wiki page than send an email to John and me, but it is worth trying. To make this clear: John and I are perfectly able to handle the incoming emails about desired additions and changes to the pages; there simply are very few of them.

This is a very good question and an important point of clarity, IMO, to realize that it's simply a matter of people not sending you emails. That's what I had assumed from my own experience (since you've always been very responsive). It seems like a cultural issue, not a technology issue, though the culture of the wiki might still be a good solution in that case. BTW, It would probably be good to have an email link from the wiki page to someone willing to input the information (for people who would rather email than edit the wiki). peace, isaac f

Manuel M T Chakravarty

20 Oct 20 Oct

9:08 a.m.

New subject: Haskell Libraries Wishlist

On Wed, 2004-10-20 at 01:22, Olaf Chitil wrote:

...

I agree that using the Wiki is a sensible compromise.

I do not quite see why more people would be willing to edit a Wiki page than send an email to John and me, but it is worth trying. To make this clear: John and I are perfectly able to handle the incoming emails about desired additions and changes to the pages; there simply are very few of them. Most entries actually are written by ourselves, just from coming across things on the various Haskell mailing lists or otherwise. This activity is too time consuming (especially writing short descriptions when it is unclear to me what the library actually does) and I only do it occasionally.

I think the later is one reason why the wiki might work better. The wiki enables everybody interested to clean up other people libraries' entries. You might ask why should anybody do this? Firstly, freshmeat does work partially because package author and freshmeat entry maintainer need not be the same person. Secondly, what happens with wikis often is that people who use the wiki to try to find some information and are not successful do update the wiki if they find this information by other means. (The occasional wiki user probably won't do that, but regular users tend to develop a sense of responsibility for the accuracy of the information.)

...

I agree with Manuel that first we need to make some changes to the Wiki page before we can expect other people to make entries there. After that is done, I'm happy to place a big forward link onto the libraries page to the Wiki libraries page. Later the old page can go when all information has been transferred.

As Manuel says we should come up with a template and explain it on the Wiki page. Each entry should certainly be short, not much more than the current: name, URL, paragraph of description. For further information there could optionally be a Wiki link to a library specific page. I don't know what to do with all the version numbers on the current Wiki page. Are they really up to date?

The page needs to be broken into several pages, because it is hard to edit a huge page with the Wiki editor. On the other hand the hierarchy should not be too deep, requiring too many pages to select and load. Basically I think we could use the existing top level of the hierarchy of the libraries&tools page. Naturally, if we want to change this hierarchy later, this will be more complicated.

Let me make a concrete proposal for a structure for the wiki and see whether we can evolve this into something everybody can agree on. Libraries & tools ~~~~~~~~~~~~~~~~~ I think we should have two separate pages for libraries and tools. These days there are just too many of both, so that the main effect of treating them together is longer, less clear pages. Having said that, we might have a top-level page which is essentially only an index for both together, but then that should point to separate pages for, eg, FFI tools and FFI libraries. Short descriptions versus table of OS/versions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Currently, haskell.org/libraries/ and hawiki differ as follows: The former lists the name of each package with a hyperlink to that packages web sire followed by a one paragraph description. In contrast, the wiki has a table listing versions on different OSes. I think we want to preserve the one paragraph description of haskell.org/libraries/, but add some of the information of the table on the wiki. I agree with Olaf that it is probably hard to keep the version numbers up to date, but what I find very useful is to have a list of the supported OSes and also the license information that the wiki provides. The hyperlink at the package name can either be a directly link to the package web page or a link to a wiki page with more information including a link to the package web page. Page structure ~~~~~~~~~~~~~~ I think we should have one wiki page for each of the following topics, separating tools and libraries (modelled after haskell.org/libraries/). More precisely, one wiki page for each "*" bullet point, which is turn is structured as indicated by the "-" points. Tools: * Program development - Compiler and compilation tools - Integrated Development Environments - Editor support - Source documentation and browsing - Testing - Tracing and debugging - Type setting - Misc * Foreign language interfacing * Web programming Libraries: * Data structures * Foreign language interfacing * Databases * Graphics and graphical user interfaces - Widget sets - Graphics - Graphics file formats * Web programming, HTML, XML * Pretty printing * Music * Mathematics and numerics * Hardware verification * Robots * Misc * Library collections Remarks: - I think "Extended Haskell" entries should be under program development. - I don't like "Interfaces to specific systems" as something like hMPI is arguably for parallel programming and all the GUI libraries are arguably also interfaces to specific systems. For similar reasons "Interfaces to databases" should be under databases. Summary ~~~~~~~ * Toplevel index page with links to topics pages * Separate topics pages for libraries and tools * Topic as listed above * Format of entries: <package name as hyperlink to further info> < ........ one paragraph description ........ > <supported OSes> <license> Cheers, Manuel

Olaf Chitil

10:21 a.m.

New subject: Haskell Libraries Wishlist

My comments on Manuel's proposal:

...

...
I do not quite see why more people would be willing to edit a Wiki page than send an email to John and me, but it is worth trying. To make this clear: John and I are perfectly able to handle the incoming emails about desired additions and changes to the pages; there simply are very few of them. Most entries actually are written by ourselves, just from coming across things on the various Haskell mailing lists or otherwise. This activity is too time consuming (especially writing short descriptions when it is unclear to me what the library actually does) and I only do it occasionally.

I think the later is one reason why the wiki might work better. The wiki enables everybody interested to clean up other people libraries' entries. You might ask why should anybody do this? Firstly, freshmeat does work partially because package author and freshmeat entry maintainer need not be the same person. Secondly, what happens with wikis often is that people who use the wiki to try to find some information and are not successful do update the wiki if they find this information by other means. (The occasional wiki user probably won't do that, but regular users tend to develop a sense of responsibility for the accuracy of the information.)

Package author and the person sending John and me an email don't need to be the same person either... However, no point going on about this issue, let's go wiki.

...

Let me make a concrete proposal for a structure for the wiki and see whether we can evolve this into something everybody can agree on.

Libraries & tools ~~~~~~~~~~~~~~~~~ I think we should have two separate pages for libraries and tools. These days there are just too many of both, so that the main effect of treating them together is longer, less clear pages. Having said that, we might have a top-level page which is essentially only an index for both together, but then that should point to separate pages for, eg, FFI tools and FFI libraries.

There had been a separate page for libraries and another one for tools for some time. John and I finally merged the two pages, because the division proved to be hard and artificial. For many tasks there exist both libraries and tools. E.g. Hood is a library for debugging, Hat is a tool. Parser combinators are in a library, Happy is a tool. So you would have mostly the same categories in both the tools and the libraries part. Usually you search for something to solve your problem and you care less if it is a library or a tool. Also many tools comprise some libraries. E.g. QuickCheck is mostly a library. Hence I think the division is unnatural for Haskell that claims embedded domain specific languages as major application area. It is hard enough sometimes to distinguish between libraries&tools and applications.

...

Short descriptions versus table of OS/versions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Currently, haskell.org/libraries/ and hawiki differ as follows: The former lists the name of each package with a hyperlink to that packages web sire followed by a one paragraph description. In contrast, the wiki has a table listing versions on different OSes. I think we want to preserve the one paragraph description of haskell.org/libraries/, but add some of the information of the table on the wiki. I agree with Olaf that it is probably hard to keep the version numbers up to date, but what I find very useful is to have a list of the supported OSes and also the license information that the wiki provides.

Many authors of small libraries have probably never thought of the license. So they should probably not be forced to list one, but it is a good option. For libraries the required language level (Haskell 98, ghc extensions, ghc&Hugs,...) might be more relevant than the OS.

...

The hyperlink at the package name can either be a directly link to the package web page or a link to a wiki page with more information including a link to the package web page.

Fine, although there might be a web link to the official package page and a Wiki link to a comments-by-the-user page.

...

Page structure ~~~~~~~~~~~~~~ I think we should have one wiki page for each of the following topics, separating tools and libraries (modelled after haskell.org/libraries/). More precisely, one wiki page for each "*" bullet point, which is turn is structured as indicated by the "-" points.

Tools: * Program development - Compiler and compilation tools - Integrated Development Environments - Editor support - Source documentation and browsing - Testing - Tracing and debugging - Type setting - Misc * Foreign language interfacing * Web programming

Libraries: * Data structures * Foreign language interfacing * Databases * Graphics and graphical user interfaces - Widget sets - Graphics - Graphics file formats * Web programming, HTML, XML * Pretty printing * Music * Mathematics and numerics * Hardware verification * Robots * Misc * Library collections

Remarks: - I think "Extended Haskell" entries should be under program development.

Not sure, but I agree that "Extended Haskell" is not good.

...

- I don't like "Interfaces to specific systems" as something like hMPI is arguably for parallel programming and all the GUI libraries are arguably also interfaces to specific systems. For similar reasons "Interfaces to databases" should be under databases.

Fine.

...

Summary ~~~~~~~

* Toplevel index page with links to topics pages

Yes.

...

* Separate topics pages for libraries and tools

No.

...

* Topic as listed above

Ok.

...

* Format of entries:

<package name as hyperlink to further info> < ........ one paragraph description ........ >

<supported OSes>

and/or required Haskell language level / compiler

...

<license>

Ciao, Olaf

Manuel M T Chakravarty

21 Oct 21 Oct

12:25 a.m.

New subject: Haskell Libraries Wishlist

On Thu, 2004-10-21 at 00:21, Olaf Chitil wrote:

...

My comments on Manuel's proposal:

...
Let me make a concrete proposal for a structure for the wiki and see whether we can evolve this into something everybody can agree on.

Libraries & tools ~~~~~~~~~~~~~~~~~ I think we should have two separate pages for libraries and tools. These days there are just too many of both, so that the main effect of treating them together is longer, less clear pages. Having said that, we might have a top-level page which is essentially only an index for both together, but then that should point to separate pages for, eg, FFI tools and FFI libraries.

There had been a separate page for libraries and another one for tools for some time. John and I finally merged the two pages, because the division proved to be hard and artificial. For many tasks there exist both libraries and tools. E.g. Hood is a library for debugging, Hat is a tool. Parser combinators are in a library, Happy is a tool. So you would have mostly the same categories in both the tools and the libraries part. Usually you search for something to solve your problem and you care less if it is a library or a tool. Also many tools comprise some libraries. E.g. QuickCheck is mostly a library. Hence I think the division is unnatural for Haskell that claims embedded domain specific languages as major application area. It is hard enough sometimes to distinguish between libraries&tools and applications.

I am not entirely convinced, but given that you have got previous experience with categorising these packages, let's just go with the combined approach as on haskell.org/libraries/ today.

...

...
Short descriptions versus table of OS/versions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Currently, haskell.org/libraries/ and hawiki differ as follows: The former lists the name of each package with a hyperlink to that packages web sire followed by a one paragraph description. In contrast, the wiki has a table listing versions on different OSes. I think we want to preserve the one paragraph description of haskell.org/libraries/, but add some of the information of the table on the wiki. I agree with Olaf that it is probably hard to keep the version numbers up to date, but what I find very useful is to have a list of the supported OSes and also the license information that the wiki provides.

Many authors of small libraries have probably never thought of the license. So they should probably not be forced to list one, but it is a good option. For libraries the required language level (Haskell 98, ghc extensions, ghc&Hugs,...) might be more relevant than the OS.

Language level is certainly a good parameter. Let's make the <supported OSes> field into a prerequisites or <supported platforms> field listing OSes, Haskell systems, and used language extensions. I don't agree entirely on the license bit, though. I am happy to list libraries that don't have a license, but nobody in their right mind would use them for any serious development, which makes them less than useful. Anyway, instead of getting into a license discussion, let's just say that we list the license if known or otherwise add the phrase "license unknown". Users can then decide whether they care or not.

...

...
The hyperlink at the package name can either be a directly link to the package web page or a link to a wiki page with more information including a link to the package web page.

Fine, although there might be a web link to the official package page and a Wiki link to a comments-by-the-user page.

If there is both, I would make the name of the package into a link to the wiki page and put the text "(website)" next to the page name with a link to the external page (the wiki will additionally put an icon next to the link indicating it is external).

...

...
Page structure ~~~~~~~~~~~~~~ I think we should have one wiki page for each of the following topics, separating tools and libraries (modelled after haskell.org/libraries/). More precisely, one wiki page for each "*" bullet point, which is turn is structured as indicated by the "-" points.

Tools: * Program development - Compiler and compilation tools - Integrated Development Environments - Editor support - Source documentation and browsing - Testing - Tracing and debugging - Type setting - Misc * Foreign language interfacing * Web programming

Libraries: * Data structures * Foreign language interfacing * Databases * Graphics and graphical user interfaces - Widget sets - Graphics - Graphics file formats * Web programming, HTML, XML * Pretty printing * Music * Mathematics and numerics * Hardware verification * Robots * Misc * Library collections

Remarks: - I think "Extended Haskell" entries should be under program development.

Not sure, but I agree that "Extended Haskell" is not good.

...
- I don't like "Interfaces to specific systems" as something like hMPI is arguably for parallel programming and all the GUI libraries are arguably also interfaces to specific systems. For similar reasons "Interfaces to databases" should be under databases.

Fine.

Integrating tools and libraries, let's start with the following index (which is a variant on the current haskell.org/libraries/ index): Tools: * Program development - Compiler and compilation tools - Integrated Development Environments - Editor support - Source documentation and browsing - Testing - Tracing and debugging - Type setting - Misc * Foreign language interfacing - Preprocessors - Libraries * Web programming, HTML, XML * Data structures * Databases * Graphics and graphical user interfaces - Widget sets - Graphics - Graphics file formats * Pretty printing * Music * Mathematics and numerics * Hardware verification * Robots * Misc * Library collections New Summary ~~~~~~~~~~~ * Toplevel index page with links to topics pages * One page per topic as listed above * Format of entries: <package name as hyperlink to further info> <optional external website> < ........ one paragraph description ........ > Everybody happy with that? Shae, given that you wrote the original wiki page, would agree that we change it as outlined above? Manuel

Shae Matijs Erisson

11:31 a.m.

New subject: Haskell Libraries Wishlist

Manuel M T Chakravarty writes:

...

Shae, given that you wrote the original wiki page, would agree that we change it as outlined above?

Well, I didn't write the original wiki page, Isaac Jones did... And the wiki culture is such that you are encouraged to make whatever changes you see fit, at any time. I've been using wikis for several years, so I'm used to a wiki process of: 1) do it 2) expect others to refine it sometimes others refine by changing it back, or by extending a structure, or by simplifying it... There are some MoinMoin macros that might make your life easier, I'll see if I can figure out exactly how they could make your life easier. -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby

Isaac Jones

1:04 p.m.

New subject: Haskell Libraries Wishlist

Shae Matijs Erisson writes:

...

Manuel M T Chakravarty writes:

...
Shae, given that you wrote the original wiki page, would agree that we change it as outlined above?

Well, I didn't write the original wiki page, Isaac Jones did...

And it has been changed a lot since then. Like I said, I have no stake in its structure and you should feel free to change it.

...

And the wiki culture is such that you are encouraged to make whatever changes you see fit, at any time.

FWIW, I concur that you're welcome to make those changes and copy the entries from the static libraries page. I don't know what should happen to the version numbers there someone (not me) did some work to get them there, but they're probably going to be very hard to keep up-to-date. The organization you posted looked fine to me, and is a good starting point. If it doesn't pan out, someone will change it :) peace, isaac

Isaac Jones

12:42 p.m.

New subject: Haskell Libraries Wishlist

Olaf Chitil writes: (snip)

...

Many authors of small libraries have probably never thought of the license. So they should probably not be forced to list one, but it is a good option.

I disagree here; I think they need to be forced to pick a license. If they don't, the default is "All Rights Reserved" (which is very different from "unknown") until they come up with something. I think that this is how the law works, and so it's how Cabal works. I also don't think we should advertise libraries that users don't have any rights to :) peace, isaac

7518

Age (days ago)

7526

Last active (days ago)

List overview

Download

21 comments

9 participants

participants (9)

Graham Klyne
Isaac Jones
John Peterson
Ketil Malde
Manuel M T Chakravarty
Olaf Chitil
Peter Simons
Shae Matijs Erisson
Simon Marlow