RE: [Haskell-cafe] Definition of the Haskell standard library
| On the other hand, it's not entirely true that there's no standard | library, it's just that it's borders are slightly fuzzy. For example, we | do have the library change submission process for modifying the standard | libraries. Up until now that has been taken to mean changes to the base | package. That package is now being split up, so we'll have to think | about what it'll apply to in the future. | | My opinion is that in the past it has been too difficult to get changes | into the base library, that there's been too much stability at the | expense of improving scope and quality. Making it easy to install new | packages and upgrade existing standard libraries should make it easier | to trial more major changes outside of the standard libs before | proposing getting those changes integrated. All true, but not so helpful for Joe User. For Joe, I think it might be helpful to have some easily-discoverable notion of which package quality and stability. - Package X is "blessed"; lots of people have argued over its design, it's stable, widely used, and actively maintained. Changes to this package goes through a quality-control process. - Package Y is a bit specialised, but it's the result of work by a small group, and it's actively maintained. - Package Z is designed, written, and maintained by one person. That person has kindly put it on Hackage so that others may share it, but you probably don't want to rely on it unless you are happy to help maintain it. Then, in effect, the "standard library" is all the X packages. I wonder if it'd help to have some descriptions such as those above (better worded), and use them? Cabal already has a "stability" indication, and that might serve, but we'd want to articulate much more clearly what it meant. Simon
On Tue, 2007-07-31 at 10:15 +0100, Simon Peyton-Jones wrote:
All true, but not so helpful for Joe User. For Joe, I think it might be helpful to have some easily-discoverable notion of which package quality and stability.
- Package X is "blessed"; lots of people have argued over its design, it's stable, widely used, and actively maintained. Changes to this package goes through a quality-control process.
- Package Y is a bit specialised, but it's the result of work by a small group, and it's actively maintained.
- Package Z is designed, written, and maintained by one person. That person has kindly put it on Hackage so that others may share it, but you probably don't want to rely on it unless you are happy to help maintain it.
Then, in effect, the "standard library" is all the X packages.
Yes.
I wonder if it'd help to have some descriptions such as those above (better worded), and use them? Cabal already has a "stability" indication, and that might serve, but we'd want to articulate much more clearly what it meant.
I'm not sure that belongs in the cabal file, afterall, being "blessed" is a central community consensus thing, not a distributed decision taken by each person writing the cabal file for their package. I can't make a blessed package by just saying that it is so. So it's clear at the moment that the base package is blessed, changes to it go through the library submissions process. It's not so clear for the other packages that ghc has distributed and have often been taken to be the standard library. Many of them look more like Y's above (like parsec, regex-*). So yes, I think we should make this clear, and that blessed packages that are covered by the library submission process should be clearly recorded and publicised centrally. Even then though, I think Chris was looking for something slightly wider. For example ghc has distributed quite a range of packages that would probably not be classified as X above, eg OpenGL, GLUT, OpenAL, FGL, HGL, etc. These are not necessarily blessed packages but are known to be of a high quality (ok, except HGL). Chris wanted to know this to distinguish from the many other packages on hackage. What is not clear to me yet is if we should just rely on mechanisms in hackage to distinguish the gems from the failed experiments or something more centralised. Duncan
On Tue, 2007-07-31 at 10:15 +0100, Simon Peyton-Jones wrote:
- Package X is "blessed"; lots of people have argued over its design, it's stable, widely used, and actively maintained. Changes to this package goes through a quality-control process.
Then, in effect, the "standard library" is all the X packages.
Duncan Coutts
I'm not sure that belongs in the cabal file, afterall, being "blessed" is a central community consensus thing, not a distributed decision taken by each person writing the cabal file for their package. I can't make a blessed package by just saying that it is so.
Yes, pretty much. The ideas mentioned in this thread for Hackage sound great. I definitely was missing a lot there, as I thought of Hackage as just somewhere people could upload their libraries. If there could be built-in quality control in promoting certain packages, that would be great. Even greater would be if: 1. Hackage tracked which packages had this "blessed" status. 2. There were a simple automated way, as part of the GHC install or otherwise immediately visible without knowing about it ahead of time, to download the whole set and install them. 3. There were either (a) a single URL that can be used to see documentation for all of them without worrying about which package something is in first; or (b) something like Cabal's haddock and install steps would combine documentation for all installed packages into a single URL; or even better, (c) both. I see it as a really big deal that documentation becomes fragmented when one is using many packages, so that it's harder to find what you want. In fact, I'd classify that as the single biggest reason that I don't use many packages now; they aren't documented at http://haskell.org/ghc/docs/latest/html/libraries/, and it's a pain to keep open several windows with documentation for different libraries. (I already have done it a lot for gtk2hs and happs, but at least it's a Big Deal to be using those, so one can justify the extra window!)
So it's clear at the moment that the base package is blessed, changes to it go through the library submissions process. It's not so clear for the other packages that ghc has distributed and have often been taken to be the standard library. Many of them look more like Y's above (like parsec, regex-*).
I've always thought of at least these packages in the existing "standard" library as being pretty stable: base, arrows, stm, mtl, Cabal, haskell-src, template-haskell, network, process, directory, filepath, unix, random, parsec, and pretty. Perhaps my perception has been skewed... but given how often these things are recommended, I'd hope they are stable.
Even then though, I think Chris was looking for something slightly wider.
I'm not entirely sure I can articulate precisely what I'm looking for. It sounds like things are going in a reasonable direction. I'll try to get my head around it, and see if I can pitch in somehow. I was simply worried that from an outsider's perspective, several recent comments in various mailing list threads, IRC dicussions, etc. seemed to predict the demise of any standard library except for base -- which would be quite disturbing given that base is becoming smaller, not larger, over time.
What is not clear to me yet is if we should just rely on mechanisms in hackage to distinguish the gems from the failed experiments or something more centralised.
Good question. I would guess the best way to answer it is to simultaneously establish something centralized in the short term, and then try to develop the technological structures to make it obsolete. -- Chris Smith
| I see it as a really big deal that documentation becomes fragmented when | one is using many packages, so that it's harder to find what you want. | In fact, I'd classify that as the single biggest reason that I don't use | many packages now When you install packages A,B,C, the documentation for A,B,C (and nothing else) ought to be locally available as an integrated whole, much as at the GHC web site. I don't know whether Cabal does, or could do, that, but it's surely what one would expect. Simon
On Tue, Jul 31, 2007 at 05:26:31PM +0100, Simon Peyton-Jones wrote:
| I see it as a really big deal that documentation becomes fragmented when | one is using many packages, so that it's harder to find what you want. | In fact, I'd classify that as the single biggest reason that I don't use | many packages now
When you install packages A,B,C, the documentation for A,B,C (and nothing else) ought to be locally available as an integrated whole, much as at the GHC web site. I don't know whether Cabal does, or could do, that, but it's surely what one would expect.
I don't think that would be terribly hard. We would need to modify Haddock with the ability to generate links following a schema like /usr/share/doc/libghc6-$lowercasepackagename/html/$modulepath.html; this would be fairly easy with Haddock-GHC's ability to access package names and ghc-pkg haddock data, assuming Cabal and Haddock-GHC are fixed to work on the same system... Stefan
Simon Peyton-Jones wrote:
When you install packages A,B,C, the documentation for A,B,C (and nothing else) ought to be locally available as an integrated whole, much as at the GHC web site. I don't know whether Cabal does, or could do, that, but it's surely what one would expect.
and would take some educating of users, like me who tend to use online resources even when there are equivalent local files available. Maybe mentioning it in the User's Guide or somewhere on the website would be enough. Actually sometimes I user-install library packages, not for the whole system; then should there be an integrated whole anywhere? Isaac
participants (5)
-
Chris Smith -
Duncan Coutts -
Isaac Dupree -
Simon Peyton-Jones -
Stefan O'Rear