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 (Igloo), who has already made a huge difference.
A highlight of the last six months was the GHC Hackathon, which we ran a immediately before ICFP in Portland, with wonderful support from Galois and Portland State University. 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. To get GHC 6.6, go to Download page. There was an extended period of release-candidate testing, so we fondly hope that this will be a relatively stable release. There are many improvements, all listed in the Release notes. The most important new features include:
Now GHC can execute several Haskell threads simultaneously on different cpus/cores
ByteString type for fast and memory-efficent string manipulations
Unicode source files
Further generalisation of newtype deriving
Bang patterns to declare function arguments as strict
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 there is current development version (HEAD), that will ultimately become GHC 6.8. You can find binary snapshots at download page or build from sources available via darcs repository. This version 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.
Andy Gill implemented the Haskell Program Coverage option (-fhpc) for GHC, which is solid enough to be used to test coverage in GHC itself. (It turns out that the GHC testsuite gives remarkably good coverage over GHC already.)
If you want to know today's state-of-the-art, you should check GHC 6.8 status page. At this moment we are working on the following features which is planned to be included in GHC 6.8 in next few months:
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 trickier, at least so far as type inference is concerned.