On Mon, 2007-07-30 at 09:19 -0600, Chris Smith wrote:
Can someone clarify what's going on with the standard library in Haskell?
As of right now, I can download, say, GHC from haskell.org/ghc and get a set of libraries with it. I can visit http://haskell.org/ghc/docs/latest/html/libraries/, linked from the haskell.org home page, and see descriptions of all of those libraries. I can build with --make (or if I'm feeling masochistic, add several lines of -package options) and it works. That's all great.
I've seen some stuff lately on -libraries and this list indicating that there's an effort to change this. People asking whether something should be included in the standard library are being told that there is no standard library really. I'm hearing that the only distinction that matters is "used by GHC" or "not used by GHC", and that being on hackage is as official as it gets.
Am I misunderstanding? Is there something awesome about Hackage that I'm not seeing?
It's not finished yet :-)
I hope one of those two is the case. Otherwise, there's a serious mistake being made here. Having a web site where people can download any of hundreds of independent libraries is not the same thing as having a good standard library for the language. I don't want to see the day when setting up Haskell involves a day-long effort of figuring out what libraries to download and install from Hackage, and in what order to do it to satisfy all the dependencies,
We have tools to solve the downloading and installing all deps problem. It's called cabal-install. It's sort-of almost ready for wider testing.
and new Haskellers poring over web sites for the thousandth time before realizing that so-and-so's GUI library hasn't actually been touched since they finished their class project in 1998 and doesn't build with the latest version of Qt or whatever.
So, yes, at the moment hackage looks like a big list of packages, but the tools for automatically downloading and installing will mature. Also we expect further improvements to hackage to do more automated QA and gather testing feedback, so we can detect and manage bitrot. People have also been talking about gathering usage stats, so one can see which out of a collection of packages in a similar area are most used. I'm sure there are other ideas that can be borrowed from CPAN and similar things. 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. Duncan