On Thu, 2009-06-04 at 16:02 +0100, Bayley, Alistair wrote:
From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Duncan Coutts
What are the code standards for the HP libs? I was under the impression that it was best to maintain H98 compatibility where possible, especially so for libraries in the old standard libs distribution. I did a quick search for platform standards but didn't find anything relevant.
It's yet to be discussed on this list. Perhaps this is a good opportunity to start that discussion. Do you want to draft a reasonable starting position?
Maybe, maybe not... I might make better progress with some more questions.
What are the long-term goals of the HP? Do you want to be able to bundle compilers other than ghc?
That's an interesting question and one I do not have a firm position on myself. The HP is supposed to be practical so I don't think we want to hold things back unduly. However if we can stick to a reasonable subset of language features then it is at least possible for other compilers to have a target. It gets harder and harder however as GHC adds more. So this is yet another question where we want to look for community discussion and try and get consensus.
At present the HP is ghc+extralibs, so we could say that anything that ghc will compile is acceptable. This does seem to preclude the possibility of bundling alternative compilers in the future, though.
So what is a reasonable common subset? Malcolm suggested: H98 + HierarchicalModules + FFI + CPP + ExistentialTypes
The subset is certainly ok. There are a number of others that are more controversial, especially the ones needed for typing the ST monad and some of the generics packages.
Do we care about compilers that are stable but not (actively) maintained? Without wanting to offend anyone here, Hugs, hbc, and nhc seem to be pretty much "feature stable". Would we rather look to the future; to compilers that support a wider range of extensions? (Rank-2 or rank-n types spring to mind, esp. in the context of the time library. That would eliminate nhc, but I think Hugs is still in the running.) MPTCs? MPTCs + fundeps?
I don't know. I'd like an answer too.
What external tools can library authors assume are available? hsc2hs? c2hs? cpphs? I see that alex and happy are specified in the haskell-platform.cabal as being present.
They can assume precisely those available in the platform. If we add cpphs and c2hs, then libs can use those.
And then there's other possible code standards...
Yep, that's a fun topic though fortunately mostly orthogonal to the issue of language extensions. Coding standards tend not to impose dependencies.
- Layout and indentation: do we run everything through a pretty printer to standardise layout?
That seems extreme to me.
- Test coverage: should we require a minimum coverage threshold from HPC?
I hope we can move in this direction.
- lint-style checks: ghc -Wall? Catch?
There's at least some subset of -Wall we can probably agree on.
- any more? ...
We've got a list of suggestions here: http://trac.haskell.org/haskell-platform/wiki/AddingPackages currently: * Does it meet a stated end-user need? * Do similar systems include such a library (e.g. Python)? * Is it portable? * Does it add additional C libraries? * Does it follow the package versioning system? * Is the code of good quality? * Does it have history? * Is it on hackage? * Does it provide haddocks? * Does it have a test suite? * Does it have a maintainer? * Does it require new Haskell dependencies? (invariant: the platform must be closed wrt. deps) * Does it have a simple/configure-based Cabal build? * Does it conflict/compete with existing functionality? * Does it reuse existing types? * Does it follow the hierarchical naming conventions? * Is it -Wall clean? * Does it have demonstrated users? * Have declared correctness or performance statements? * Is it BSD licensed? * Will the maintainer continue to maintain it, as demand grows ? * Is it thread-safe? Duncan