Difference between revisions of "Haskell Platform"

Revision as of 18:17, 24 July 2008

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.

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.

Discussion

A discussion took place in June and July 2008 about the direction of the HLP.
More occured during the #ghc meeting

Next Steps

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.

Criteria

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 upgradable

Quality Control

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.

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.

Distribution format

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?

Current library set

Core system

This will be on every system, as they're required for GHC to build:

array
base
bytestring
Cabal
containers
directory
editline
filepath
haskell98
hpc
integer-gmp
old-locale
old-time
packedstring
pretty
process
random
template-haskell
unix OR Win32

Extra libraries

Current libraries available in the 'extralibs' bundle provided with GHC, a descendent of what used to by fptools, with a few additions.

ALUT
GLUT
HUnit
ObjectIO
OpenAL
OpenGL
QuickCheck
cgi
fgl
haskell-src
html
mtl
network
parsec
parallel
regex-base
regex-compat
regex-posix
stm
time
xhtml

HLP: Batteries Included

/Batteries_Included

Tools

Language-processing tools should probably also be considered to be part of the platform. Commonly-needed tools include:

ghc
happy
alex
haddock
cpphs
cabal-install (now known simply as cabal?)

What else might we consider?

DrIFT or derive
throw in another compiler - e.g. Hugs?
c2hs
hsc2hs

Release mechanics

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"

History

fptools
extralibs/ core libs

@@ Line 46: / Line 46: @@
 * 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 upgradable
 ===Quality Control===
 * 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.
@@ Line 59: / Line 63: @@
 * exposed module names must follow the hierarchical module name convention, meaning they must be in an appropriate place in the module namespace.
+=== 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.
 == Distribution format ==