Difference between revisions of "Haskell Platform"
DonStewart (talk | contribs) |
DonStewart (talk | contribs) |
||
Line 92: | Line 92: | ||
Additionally, if a library is accepted into the platform, it is suggested its version number be lifted to 1.0, if not already at 1.0. |
Additionally, if a library is accepted into the platform, it is suggested its version number be lifted to 1.0, if not already at 1.0. |
||
+ | |||
+ | == Licenses == |
||
== Related projects == |
== Related projects == |
Revision as of 08:24, 30 September 2008
Haskell: Batteries Included
The Haskell Platform (HP) is the name of a new "blessed" library suite on which to build further Haskell libraries and applications, by taking the best libraries from the nearly 800 libraries of haskell.org. It provides a comprehensive, stable and quality tested base for Haskell projects to work from.
Resources
- Haskell Platform project repository
- Project bug tracker: candidates for inclusion
Documentation
- The Haskell Platform Proposal for the 2008 Haskell Symposium
- Slides from the Haskell Platform talk
- Haskell Platform discussion
- Bryan O'Sullivan's writeup of the future of Haskell discussion
- A discussion took place in June and July 2008 about the direction of the HLP.
- More occurred during the #ghc meeting
Quality Control
Inclusion or exclusion in the platform will be drive by metrics, objective measurements we can extract from code. Determining appropriate metrics is a milestone.
- cabal-installable libraries with haddocks.
- The set of HP packages + core libs must be closed. That is all haskell dependencies must be from within the HP packages or core libs. Dependencies on C libs can be external.
- All packages in a particular HP version must have a consistent install plan.
That means only one version of each package and all dependencies on packages must be satisfied by the version in the HP package set.
There is code in cabal-install to check the last two requirements.
Other possible ideas for quality standards we might want to require:
- Uses base library types, to force API standardisation
- exposed module names must follow the hierarchical module name convention, meaning they must be in an appropriate place in the module namespace. In particular, no clash of module names should occur within the HP.
Glue Layers
Unlike the OCaml Batteries proposal, there will be no new glue layer to combine libraries, instead, we rely on the large base library to provide the standard interface types.
As addition to the platform is a social process, we can use this as a hurdle to require base library conformance for new libraries to be admitted. If a library reinvents, for example, a time format, or an exception handling mechanism, the platform process will force standardisation on the base API before admition can proceed.
Other heuristics
Packages set for inclusion should:
- Have a maintainer
- Have a bug tracker
- Use the correct versioning
- Build with cabal
- Work on all arches.
Further goals:
- -Wall clean
- 100% coverage
- Have real world use.
- Answer a notable set of build dependencies.
Distribution format
- Source distribution
- .tar.gz bundle compatible with extra-libs
- Windows Installed
- Native distro packages
The HP will be the first meta-package on hackage, that depends on the platform library set. With this,
cabal install haskell-platform
will be possible.
Version policy
yyyy.major.minor,
- odd major numbers indicate unstable branches
- minor numbers indicate bug fixes only, no API changes.
Examples:
- 2008.0.0 -- first biannual major stable release
- 2008.0.1 -- minor release, bug fix only
- 2008.1 -- unstable branch leading to next major release
- 2008.2.0 -- second annual major release, API changes
- 2008.2.1 -- bug fixes
- 2008.3 -- unstable branch of 2008
- 2009.0.0 -- first release in 2009.
Additionally, if a library is accepted into the platform, it is suggested its version number be lifted to 1.0, if not already at 1.0.
Licenses
Related projects
Developers
Haskell Platform core team:
- Duncan Coutts (Well Typed)
- Don Stewart (Galois)