Glasgow mafia meeting at PLDI

Simon Marlow simonmar@microsoft.com
Tue, 26 Jun 2001 12:49:32 +0100


First of all, many thanks to Alastair for typing up the notes from this
gathering.

I'll add that the latest version of the document is up, at:

	http://www.haskell.org/~simonmar/libraries/libraries.html

and explains in more detail some of the points that Alastair mentions
below.  There are still lots of blank bits.  Please send me any
corrections or suggested text for inclusion.  This document will be in
the repo as soon as I get around to it.

(my apologies to the Mathematics guys, I haven't updated the document
w.r.t. your latest discussions yet). =20

Quick status update on the core libraries: I've moved over all of GHC's
std and lang packages to the new framework, and have the whole thing
building and producing a useable Prelude.  Object splitting doesn't work
yet.  I'll commit what I have later this week so folks can take a look
(there are some other changes required to GHC to make it all work, I
haven't decided how to commit these without breaking the compiler yet.).

> 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.
>=20
>    "Domain" was the best alternative we thought of - but it felt
>    a bit lame.

Indeed, better suggestions are welcome.

> 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. =20
>    (Next time I'm hacking on the exceptions, I'll probably=20
>    add Dynamic in there.  Hugs hackers should feel free to add
>    it first.)

Let's face it, at the moment you also need I/O "in the Prelude" so I'm
not convinced by the argument that the Prelude is getting bloated.  In
the new library scheme, the Prelude simply re-exports lots of other
stuff from the hierarchy, so in fact you need a large chunk of it
anyway.  I don't think Hugs' startup times will be an issue; if they are
then I think the right thing to do is to slim down the Prelude itself.

> 5) We talked a bit about versions.  Two attitudes:
>=20
>    1) It is just silly to want to have two different versions of a=20
>       given library in the same program.  We don't have the manpower
>       to cope with the complexity.  Java doesn't try to tackle this.
>=20
>    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?
>=20
>    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?)

I think we agreed that it was necessary to place a version on the set of
modules as a whole, so you can match library versions with compiler
versions, and identify stable points and points when particular
functionality was introduced or changed.  I had intended to tie this in
with the notion of stability - eg. minor version updates can't change
the API of a stable library, see the document for the details.

> 7) I abdicated from the position of Hugs Library Czar and Andy Gill
>    assumed the position.
>=20
>    My resignation didn't go into effect until 7am today so I could
>    legitimately claim that I was the HLC on my CV :-)

The document now mentions the core team and its purpose /
responsibilities.

> 8) Portability
>=20
>    All the core libraries will be required to work on all compilers
>    (defined to mean GHC, NHC and Hugs).

Actually, all the core modules marked as *portable* will be required to
work on all compilers.  All the other modules are optional, but are
expected to work with a given compiler/platform combination if (a) the
compiler supports any required extensions, (b) the module's dependencies
are all satisfied, and (c) the module is compatible with the target
platform.

>    Less portable libraries should be labelled (where?)

in the module header, see the document.

> 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=20
> concurrency, ...
>=20
>    There seems to be some kind of connection here between:
>=20
>    1) What you put in a package description to cause both GHC and Hugs
>       to accept code which uses MPTC.
>=20
>    2) What #ifdef you put in the source code to handle code that needs
>       MPTC on compilers that lack it.
>=20
>    3) The list of non-portable features a library requires.
>
> 9) Responsibilities of people committing code
>=20
>    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.
>=20
> 10) Committing broken code to the CVS repository
>=20
>    (Broken =3D=3D 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.)
>=20
>    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.

Our lives will be a lot easier if we set up an infrastructure that lets
you build all the libs and run tests for all the compilers with minimal
hassle.  With this in place, we can legimately claim that anyone who
commits broken code deserves a red hot poker up the jacksie.

Julian Seward's new testsuite stuff is coming along nicely, and should
provide us with a good starting point for setting up the tests (see
fptools/testsuite).

> 11) Maintainer
>=20
>   Every library will have a single maintainer who acts as a single=20
>   point of contact for the library.
>=20
>   [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???]

Yup, that's about the size of it.  The document makes it a bit clearer.

> 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.

and I have the photos to prove it - hopefully available later today...

Cheers,
	Simon