The next step

Simon Marlow simonmar@microsoft.com
Fri, 25 May 2001 13:05:23 +0100


Hi folks,

I'd like to propose a way forward for developing the library collection.
Apologies for the huge message ... ;-)

The guiding principle I think we should use is one of "devolved
responsibility": that is, rather than choose a committee of people to
oversee the project, we let the community at large do it.  Individual
libraries will have their own keepers: either authors or a small group
of interested individuals.

Having said that, there will occasionally be a need for a way to resolve
disputes and a driving force to keep the project headed in the right
direction.  Therefore I suggest we start with a single representative
from each compiler camp (to avoid any drift toward one particular
implementation and try to keep us on the straight and narrow
portability-wise).  Initially this would be Malcolm, myself, and someone
from the Hugs camp yet to be decided.  Our primary responsibilities
would be

   - assigning control of libraries to individuals,
   - allocating places in the "managed" portion of the hierarchy
   - advising on style and portability policies, developing and
     maintaining style and portability guidelines
   - trying to keep things consistent across the hierarchy

The next step is to write a document setting out the conventions and
guidelines for the library collection.  There's a rough outline below,
which mentions several points we still need to resolve.

- Haskell Libraries Document ---------------

  - License (specify?)

  - Hierarchy design guidelines

    - Hierarchy layout guidelines/policy.
      - Allocation of top-level categories:
        - "managed" categories
        - domain names or email addresses

    - Naming policy for modules
      - abbreviate / don't abbreviate (Network vs. Net)
      - pluralise / don't pluralise (Generics, Dynamic)
      - follows name of type/class or describes functionality
      - capitalization of acronyms
 =20
  - Library status
    - experimental/stable
    - compiler-specific/portable.
 =20
  - Portability considerations

  - Library ownership
    - responsibilities of library owner

  - Documentation
    - HaskellDoc?

  - Versioning
    - of the whole collection
    - of individual modules (can a module exist with several versions
      simultaneously, can you import a specific version?)

  - Haskell library style and naming conventions
    - function/type/class naming guidelines
      - assume qualified import? (IORef.new vs. newIORef)
      - for a module which provides an instance, should it also export
        non-overloaded versions of the methods (like Edison)?
    - standard module header
      - copyright
      - status (stable, experimental)
      - portability (standard, specific to certain compilers)

  - Testing policy
    - libraries should come with a test suite.

-------------------------------

Comments and opinions on any of the issues from the list above are
welcome...
here are a couple of thoughts off the top of my head:

  - License: I'd prefer to specify a BSD-style (without advertising
    clause) license, with copyright on individual files remaining with
    the authors.  GPL code creates particular problems for us here,
    so I'm keen to avoid it if possible.

  - Let's aim for HaskellDoc long term, but since we're not close to
    arriving at a proposal for the documentation syntax we shouldn't
    wait for it - libraries can be converted to HaskellDoc later.

For the centralised source repository we can use cvs.haskell.org, with a
new 'libraries' module; library owners can be given accounts to maintain
their own libraries.  The source tree will need build systems for the
different compilers (for GHC I'll probably arrange things so that
libraries can be grafted onto fptools/ and use the build system there).

Cheers,
	Simon