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 - Library status - experimental/stable - compiler-specific/portable. - 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