GHC Status October 2006

GHC is in good shape. We have no good way to measure how many GHC
users there are, but if the traffic on the GHC mailing lists is
anything to go by, the numbers are increasing quite rapidly. Indeed,
GHC was rapidly becoming a success-disaster, so that we (Simon &
Simon) were becoming swamped in GHC-related mail. Happily,
Microsoft Research has agreed to fund a full-time support engineer,
in the form of Ian Lynagh, who has already made a huge difference.

Other highlights of the last six months are these:

With wonderful support from Galois and Portland State University, we ran a GHC Hackathon immediately before ICFP in Portland. Forty-plus people showed up to have GHC's innards inflicted on them, and appeared unharmed by the experience.

A significant outcome is that we have written a great deal of Wiki material about GHC's implementation (the "commentary"), and about how to build and modify GHC (the "building guide"). Documents with these titles were available before, but had become rather out of date. These new, up-to-date documents live on the GHC developer's Wiki. We urge you to read and improve them: ​http://hackage.haskell.org/trac/ghc/wiki (near the bottom).

We (finally) released GHC 6.6 in October 2006. There was an extended period of release-candidate testing, so we fondly hope that this will be a relatively stable release. Main improvement over GHC 6.4 is support for SMP systems - now GHC can execute several Haskell threads on different cpus/cores. There also lot of other improvements, stare at ​Release notes and jump to Download page to get it. Significant new features, all described in modre detail in the release notes, include:

Support for multi-processors

Impredicative polymorphism

Bang patterns

Unicode source files

Further generalisation of newtype deriving

Monomorphic pattern bindings

Lastly, we finally bit the bullet and lifted the restriction that every module in a Haskell program must have a distinct name. Why? Because it's non-modular: two packages from different authors could accidentally collide. This change is in GHC 6.6; there are some remaining open choices dicussed here ​http://hackage.haskell.org/trac/ghc/wiki/GhcPackages.

Life still goes on, and current HEAD version ​http://darcs.haskell.org/ghc/ that will ultimately become GHC 6.8 already includes significant new features:

We have completely replaced GHC's intermediate language with System FC(X), an extension of System F with explicit equality witnesses. This enables GHC to support GADTs and associated types, with two new simple but powerful mechanisms. The paper is at ​http://research.microsoft.com/%7Esimonpj/papers/ext-f/. Much of the conversion work was done by Kevin Donnelly, while he was on an internship at Microsoft.

At the moment GHC's garbage collector is single-threaded, even when GHC is running on a multiprocessor. Roshan James spent the summer at Microsoft on an internship, implementing a multi-threaded GC. We need to do a bit more work, but with a bit of luck we'll push a parallel garbage collector into the HEAD before Christmas.

Simon PJ is determined to finally implement implication constraints, which are the key to fixing the interaction between GADTs and type classes. GHC's users have been very polite about this collection of bugs, but they should really be fixed. Implication constraints are described by Martin Sulzmann: ​http://www.comp.nus.edu.sg/~sulzmann/publications/tr-eadt.ps.gz.

Once the last bits of indexed data types are done, Manuel will be tackling indexed type synonyms (aka type functions), which are considerably tricker, at least so far as type inference is concerned.