Haskell: Batteries Included
The Haskell Platform (HP) is the name of a proposed library set that would be the minimum standard for Haskell library support on a system.
More generally, if we want tools as well as libraries, then the simpler name Haskell Platform may be more appropriate than the original name Haskell Library Platform.
There are now more than 500 libraries available for Haskell, on hackage. Choosing which libraries to support on a distro is currently done on an ad hoc basis, with significant variation from one distribution to another.
Some, such as Arch Linux, or Gentoo Linux, include as many libraries as possible (typically over 400), while others have the bare minimum required to build ghc and say, darcs and xmonad.
The Haskell community needs to provide direction and blessing to a library set that should be available and adopted, to further encourage Haskell use.
Ensuring that the chosen set of library versions works well together, and with a particular version of GHC (and other tools), is a major goal.
- A proposal paper for the 2008 Haskell Workshop.
- A discussion took place in June and July 2008 about the direction of the HLP.
- More occurred during the #ghc meeting
The next step in the process:
- Define admission progress: how does a package get into the HLP
- Sort out the release team
- Define the installation expectations
- Set up a bug tracker for the HLP project.
- Create a repo.
- GHC would build against its own core libraries, but would be generally distributed with the HLP.
- The HLP should provide good coverage for all typical tasks one might want to accomplish with the language, given library availability.
- No bottlenecks: release of the HLP should be entirely independent from GHC, and also independent of the development cycle of any individual library or tool.
- HP should be separately upgradeable
- 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:
- 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.
Packages set for inclusion should:
- Have a maintainer
- Have a bug tracker
- Use the correct versioning
- Build with cabal
- Work on all arches.
- -Wall clean
- 100% coverage
- Have real world use.
The HP can be a meta package on hackage.haskell.org, that simply depends on the core set.
cabal install hp
should work, for example.
Beyond this, we'll need a why to provide single tarballs of the set, windows installers et al. Will GHC need cabal-install?
platform would be much more descriptive as a name for this package MichalPalka 23:56, 24 July 2008 (UTC)
Current library set
This will be on every system, as they're required for GHC to build:
- unix OR Win32
Current libraries available in the 'extralibs' bundle provided with GHC, a descendent of what used to by fptools, with a few additions.
HLP: Batteries Included
Language-processing tools should probably also be considered to be part of the platform. Commonly-needed tools include:
- cabal-install (now known simply as cabal?)
What else might we consider?
- DrIFT or derive
- throw in another compiler - e.g. Hugs?
Public "Haskell Platform Compliant" list
To encourage adoption of the HLP, distributions that support the HLP will be publically listed as e.g. "Haskell Platform Compliant"
- extralibs/ core libs