wiki:Status/October06

Version 22 (modified by simonpj, 7 years ago) (diff)

--

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.

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. There was an extended period of release-candidate testing, so we fondly hope that this will be a relatively stable release. The main improvement over GHC 6.4 is support for SMP systems - now GHC can execute several Haskell threads on different cpus/cores. There also many other improvements, listed in the Release notes. To get GHC 6.6, go to Download. Significant new features, all described in more 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 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.)

We are now working on lots of new stuff that isn't yet in GHC HEAD but will end up there if all goes well, and then become a part of GHC 6.8:

  • 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.

Simon, Simon, with help from Manuel, Bulat and others, October 2006