Dear library folk Dominic has been writing a crypto library: | I'm not clear what happens at the moment. I had naively assumed that having | created my library that it would be put into the ghc cvs repository and | would then be available in the same way other libraries are when you install | ghc. | | Do libraries get put into the ghc cvs repository? | If they do, do they get put into the ghc release? | If they don't then how does someone who wants to use one get hold of it? George wants Koen's Chunk library: | > Take a look at: | > | > http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/Lab2/Chunk.hs | > | > Is that what you want? | Yes, that's much more like it. Any chance of this module getting put into | the standard distribution? These both raise a common question: how can someone distribute a library? (This is a different question to the library-infrastructure question about how to build a library, which we've been discussing recently.) What Dominic and George would like is for their desired library to just "come with GHC" (and Hugs, NHC). But this model is unsustainable for us (the GHC team), and I expect it is unsustainable for Hugs and NHC. It's just too much work to be responsible for all the libraries that anyone might contribute. Adding just one more module isn't a problem, but iterating that process certainly is. Simon and I are beginning to sink --- partly a welcome side effect of GHC's widespread use --- so we need to find ways to get ourselves off the critical path for libraries, to avoid impeding their development. (As I remarked in an earlier message, I think that ways to make libraries flourish is the top challenge facing the Haskell community.) The main alternative to "packaged by the GHC/Hugs/NHC team" route is this: the person writing the library makes it into a separate GHC package (and something similar for Hugs, NHC), and distributes it separately This is the model followed by Sven's GLUT package, for example. GLUT is physically kept in the GHC/Hugs CVS library repository, but Sven maintains and distributes it. He can fix bugs, and distribute new versions whenever he likes, independent of GHC releases. This is quite a high-cost model, though. It's a fair amount of work to build binary distributions of libraries for different platforms and for different Haskell implementations. For example, I can't see Koen doing that just for his one-module Chunk library; and Dominic might find it a bit daunting for his crypto libraries too. What we want, I think, is an aggregation mechanism. In particular there could be one or more "contrib" packages, optionally hosted at fptools/libraries, containing code contributed and maintained by different folk, but packaged and distributed by one person, a Contrib Builder (better titles welcome) Note that a) A Contrib Builder may, but does not have to, use the library infrastructure we are discussing in another thread. But s/he will need to provide some infrastructure so that people contributing libraries can build and test their library. The Contrib Builder will probably want to do automated nightly build/test runs of the package. b) A given package (= group of library modules, distributed as a single bundle) can have a Contrib Builder for GHC, another for Hugs and another for NHC. That's the way the core libraries work right now: there's a single shared code base in fptools/libraries, and the GHC, Hugs and NHC teams each build distributions from that common code base. When a new version of GHC/Hugs/NHC comes out, the appropriate Conrib Builder(s) should make a new version of their package for the new version of the compiler, if necessary. But of course, the package can be released more frequently than that. c) There can be more than one contrib package. A package is just a unit of distribution, to amortise the cost of building distributions for multiple modules. Ideally, a package would contain thematically related modules, but not necessarily. d) Every module in a package will occupy a slot in the common hierarchical module name space; so library authors should negotiate for their name, using the libraries mailing list, as they do now. OK so that's the idea. 1. Does it seem like a reasonable idea? 2. There is a pressing need for the first Contrib Builder for libraries like Dominic's crypto and Koen's Chunk library. Any volunteers? Even for one implementation target? Simon