We got 4 Glaswegians (Andy Gill, Andy Moran, Simon Marlow and me) together in the same room at PLDI for a meeting about the new library scheme. The following is an attempt to summarise what was said. (I'm omitting a bunch of recapping what SimonM has already mailed to this list and I'm surely misrepresenting what was said - it's hard to keep it all straight after your third latte.) 1) SimonM explained the language change needed to support the module hierarchy. 2) Whilst looking through the hierarchy, we decided that using "Org" was a bit unfortunate since it could lead to silly-looking names like Org.Org.Haskell.... and, worse, downright confusing names like Org.Com.Galois. "Domain" was the best alternative we thought of - but it felt a bit lame. 3) I lamented the fact that GHC's Exception type requires Dynamic which, in turn, requires that GHC's Prelude contain Dynamic. If Hugs were to follow suit, Hugs' Prelude would also have to contain Dynamic - I don't especially like the way the Prelude gradually sucks all functionality into itself. I got little sympathy and I think Moore's law was mentioned. (Next time I'm hacking on the exceptions, I'll probably add Dynamic in there. Hugs hackers should feel free to add it first.) 4) SimonM showed us what Prelude.hs looks like in the new scheme: module Prelude( <huge list goes here> ) where #if defined GHC import GHC.Primops import GHC.WeirdWackyStuff import GHC.IO #elsif defined Hugs import Hugs.PreludeList import Hugs.<whatever> #elsif ... #endif Looks cool. Won't work on Hugs because Hugs insists that the Prelude be the first module loaded but under this scheme, the Prelude is only loaded after loading the Hugs.* stuff. Fortunately, I fixed this deficiency in STG-Hugs so all we have to do is copy the diffs over. IIRC, the changes to support this were in a separate commit so it should be easy. In my copious free time, I'll try to get this copied over. 5) We talked a bit about versions. Two attitudes: 1) It is just silly to want to have two different versions of a given library in the same program. We don't have the manpower to cope with the complexity. Java doesn't try to tackle this. 2) I'll bet that's what the glibc folk thought too. Do we have the manpower to keep the whole libraries (and stuff not in the main repository) in lockstep? I recalled someone saying that when Java added their name hierarchy, they had the opportunity to deal properly with versioning but couldn't remember what had been suggested as the Right Thing to do. I said I'd look around for anything reasonably palatable that we could do. (First place to look is on this list - any suggestions?) 6) GHC's deprecated pragma is cool and would probably be easy to add to Hugs. Maybe Johan could be persuaded? 7) I abdicated from the position of Hugs Library Czar and Andy Gill assumed the position. My resignation didn't go into effect until 7am today so I could legitimately claim that I was the HLC on my CV :-) 8) Portability All the core libraries will be required to work on all compilers (defined to mean GHC, NHC and Hugs). Less portable libraries should be labelled (where?) with a list of features that they require (or, looking at it another way, a list of features that prevent it from being portable). Examples include, MPTC, unboxed ints, concurrency, preemptive concurrency, ... There seems to be some kind of connection here between: 1) What you put in a package description to cause both GHC and Hugs to accept code which uses MPTC. 2) What #ifdef you put in the source code to handle code that needs MPTC on compilers that lack it. 3) The list of non-portable features a library requires. 9) Responsibilities of people committing code We pondered requiring an extra layer of review before anyone is allowed to commit to the libs designated as portable and stable. (This is required in the OpenBSD kernel.) We saw the attraction but I'm not sure that anyone wanted to actually do it. 10) Committing broken code to the CVS repository (Broken == not as portable as the lib claims to be, accidentally reducing portability, breaking a library that depends on it. Doing something to the code for someone else's compiler that they would find intolerable if it happened to the version used with their favourite compiler. A good approximation is anything that will break the regression suite.) Is it ok to commit broken code? If so, how long can it remain broken before someone has to fix it? Who's responsibility is it to fix the code. I think the mood was "it's not ok" and "fixing should take priority over everything else" and is the responsibility of the person who committed it. We talked somewhat aimlessly about (the usual idea of) setting up a machine whose only job is to keep trying to compile all the code and run all the tests. Andy Gill suggested two useful ideas: 1) Define clusters of tests - some of which are so cheap to try that you can reasonably be expected to try them before doing a commit. (At least with Hugs and NHC which have more reasonable build times than GHC and all its little ways.) They would then get increasingly expensive until you reach the ones that are so expensive that you have to do round-robin scheduling between clusters "it's Tuesday so I'd better try bootstrapping GHC with itself on the ZX81 port". 2) Every time the test machine successfully runs the test suite, it should tag all the files with the tag "last_stable_version". Those who find themselves able to resist the bleeding edge would tend to use this. [As far as I can tell, this approach will make it safe to do a checkout anytime you like. Unfortunately, it still won't be possible to commit into the head until the head is made stable again - so it won't eliminate the need to be careful not to break the head. - ADR] 11) Maintainer Every library will have a single maintainer who acts as a single point of contact for the library. [But some of the discussion seemed to suggest that the maintainer could be a group of people so maybe SimonM meant that there's a single email address to write to???] 12) Licenses I think we decided that the essence of the BSD/LGPL debate was: o BSD fans think that "contamination" is bad o LGPL fans think that "contamination" is good This is basically a religious argument on which no agreement is likely to be reached by zealots on either side. As far as I [ADR] can tell, the debate about just how the LGPL applies to Haskell is a red-herring. Even if we understood it and agreed it was reasonably specified and appropriate in a Haskell context, BSD fans would still not want LGPL. (That's certainly my own feeling.) Or, to put it another way, we (had already?) agreed to disagree and the repository will be partitioned into 2 separate repositories and packages will contain either pure BSD code or pure LGPL code. [The Galois people (Andy and Andy) actually work at one of the few places that really does have significant intellectual property written in Haskell. I won't attempt to summarise their position on the license issue or their argument but would encourage them to do so. Incidentally, it seems that Andy Gill hasn't been getting library email for the last few weeks - which explains why they've been so quiet.] At this point we heard the mountains calling to us and felt obliged to answer the call. I'm glad to report that no plants were harmed in the process and that we gave the summits the respect they deserve by strenuously avoiding any summit-like points on the trail. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/