Glasgow mafia meeting at PLDI

[Alastair David Reid]

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/