Changes between Version 1 and Version 2 of Status/Oct09

Nov 3, 2009 1:33:38 PM (6 years ago)



  • Status/Oct09

    v1 v2  
    11= GHC status October 2009 = 
    3 We are just about to make our main annual release, of GHC 6.12. 
     3We are just about to make our annual major release, of GHC 6.12.1 (in the following we will say "GHC 6.12" to refer to GHC 6.12.1 and future patch-level releases along the 6.12 branch). 
     5GHC continues to be very active, with many opportunities 
     6for others to get involved.  We are particularly eager to find partners 
     7who are willing to take responsibility for a particular platform  
     8(e.g. '''Simon M fill in the most popular Tier 2 plaform'''); see [Platforms]. 
     10== The GHC 6.12 release ==  
     12We usually try to make a major release of GHC immediately after ICFP. 
     13It has been somewhat delayed this year, but we expect to release  
     14GHC 6.12 during November or December 2009.  Apart from the myriad of 
     15new bug fixes and minor enhancements, the big new things in 6.12 are: 
     17 * Considerably improved support for parallel execution.  GHC 6.10 
     18   would execute parallel Haskell programs, but performance was often 
     19   not very good.  Simon Marlow has done lots of performance tuning 
     20   in 6.12, removing many of the accidental (and largely invisible) 
     21   gotchas that made parallel programs run slowly. 
     23 * As part of this parallel-performance tuning, Satnam Singh and Simon 
     24   Marlow have developed ThreadScope, a GUI that lets you see what is 
     25   going on inside your parallel program.  It's a huge step forward 
     26   from "It takes 4 seconds with 1 processor, and 3 seconds with 8 
     27   processors; now what?".  ThreadScope will be released separately 
     28   from GHC, but at more or less the same time as GHC 6.12. 
     30 * Dynamic linking is now supported on Linux, and support for other 
     31   platforms will follow.  Thanks for this most recently go to 
     32   the [ Industrial Haskell Group] (thank you, IHG!) who 
     33   pushed it into a fully-working state; dynamic linking is the culmination of the work of 
     34   several people over recent years.[[BR]] 
     35   [[BR]] 
     36   One effect of dynamic linking is that binaries shrink dramatically, because the run-time 
     37   system and libraries are shared.  Perhaps more importantly, it is possible 
     38   to make dynamic plugins from Haskell code that can be used from other 
     39   applications. 
     41 * The I/O libraries are now Unicode-aware, so your Haskell programs 
     42   should now handle text files containing weird characters. 
     44 * The package system has been made more robust, by associating each 
     45   installed package with a unique identifier based on its exposed ABI. 
     46   Now, cases where the user re-installs a package without recompiling 
     47   its dependencies will be detected, and the broken dependencies will 
     48   be disabled.  Previously, this would lead to obscure compilation errors, 
     49   or worse, segfaulting programs.  This involved a large amount of 
     50   internal restructuring, but it paves the way for future improvements 
     51   to the way packages are handled.  For instance, in the future we 
     52   expect to track profiled packages independently of non-profiled ones, 
     53   and we hope to make it possible to upgrade a package in an ABI-compatible 
     54   way, without recompiling the packages that depend on it.  This latter 
     55   facility will be especially important as we move towards using 
     56   more shared libraries. 
     58 * A variety of small improvements to data types: record punning, 
     59   declararing constructors with class constraints, GADT syntax for 
     60   type fammilies etc. 
     62 * You can omit the "`$`" in a top-level Template Haskell splice, which 
     63   makes the TH call look more like an ordinary top-level declaration with 
     64   a new keyword. 
     66 * We're are deprecating `mdo` for recursive do-notation, in favour of 
     67   the more expressive `rec` statement. 
     69 * We've concluded that the implementation of impredicative 
     70   polymorphism is unsustainably complicated, so we are re-trenching. 
     71   It'll be depreceated in 6.12 (but will still work), and will be either 
     72   removed or replaced with something simpler in 6.14. 
     74For more detail, see the release notes in the  6.12 User manual [UM],  
     75which mention many things skipped over here. 
     77Another big change with GHC 6.12 is that Hackage and the Haskell Platform is 
     78allowing GHC HQ to get out of the libraries business.  So the plan is 
     80 * We release GHC 6.12 with very few libraries 
     81 * Bill Library Author downloads GHC 6.12 and tests his libraries 
     82 * The next Haskell Platform release packages GHC 6.12 with these tested libraries 
     83 * Joe User downloads the Haskell Platform. 
     84 * Four months later there's a new HP release, still with GHC 6.12, 
     85   but with more or better libraries.  The HP release cycle is 
     86   decoupled from GHC 
     88So if you are Joe User, you want to wait for the HP release.  Don't 
     89grab the GHC 6.12 release.  It'll be perfectly usable, but only if you 
     90use (an up to date) cabal-install to download libraries, and accept that 
     91they may not be tested with GHC 6.12. 
     93Lastly, GHC 6.12 has a totally re-engineered build system, with much-improved 
     94dependency tracking [BuildSystem].  While there have been lots of teething problems, the  
     95old system had become increasingly troublesome, so we had to make a change. 
     97== What's hot for the next year == 
     99GHC continues to be a great substrate for research.  Here are the main things 
     100we are working on at the moment. 
     102=== Type systems === 
     104Type families have proved a great success.  From the outside it might 
     105seem that they are done -- after all, they are in GHC 6.10 -- but the 
     106internals are quite fragile and it's amazing that it all works well as 
     107it does.  (Thanks to Manuel's work.)  Tom Schrijver, Dimitrios 
     108Vytiniotis, Martin Sulzmann, and Manuel Chakravarty have been working 
     109with Simon PJ to understand the fundamentals and, in the light of that 
     110insight, to re-engineer the implementation into something more robust. 
     111We have developed the "!OutsideIn" algorithm, which gives a much nicer 
     112account of type inference than our previous story of type inference 
     113[ICFP09].  More controversially, we now believe that local let/where 
     114bindings should not be generalised [LetGen].  Dimitrios is building a 
     115prototype that embodies these ideas, which we'll then transfer into 
     118Meanwhile, Dimitrios, Simon, and Stephanie Weirich are also working on 
     119fixing one of GHC's more embarassing bugs (Trac #1969 '''Simon check'''), 
     120whereby an interaction of type families and the newtype-deriving can 
     121persuade GHC to generate type-unsound code. It's remained un-fixed 
     122because the obvious approaches seem to be hacks, so the cure was as 
     123bad as the disease.  We think we are on to something; stay tuned. 
     125=== Interemediate language and optimisation === 
     127Although it is, by design, invisible to users, GHC's intermediate language 
     128and optimsation passes have been receiving quite a bit of attention. 
     129Some highlights 
     131 * Read Max Bolingbroke's paper on Strict Core [MaxB], a possible new 
     132   intermediate language for GHC.  Adopting Strict Core would be a Big  
     133   Change, however, and we have not decided to do so (yet). 
     135 * Simon PJ totally re-engineered the way that INLINE pragmas are  
     136   implemented., with the goal of making them more robust and  
     137   predicatable [InlinePatch].  There's a new CONLIKE pragma which 
     138   affects rule matching. 
     140 * Peter Jonsson did an internship in which he made a start on turning 
     141   GHC into a supercompiler.  Neil Mitchell's terrific PhD thesis suggested 
     142   that supercompliation works well for Haskell [NeilM], and Peter has been working on 
     143   supercompilation for Timber as part of his own PhD [Peter J]. 
     144   The GHC version isn't ready for prime time yet, but Simon PJ (now 
     145   educated by Peter and Neil) is keen to pursue it. 
     147 * An internal change in GHC 6.12 is the addition of "annotations", a 
     148   general-purpose way for a programmer to add annotations to 
     149   top-level definitions that can be consulted by a core-to-core pass, 
     150   and for a core-to-core pass to pass information to its successors 
     151   [Annotations]. 
     152   We expect to use these annotations increasingly in GHC itself. 
     154=== Parallelism === 
     156SIMON MARLOW to write 
     158=== Data Parallelism === 
     160MANUEL CHAKRAVARTY to write 
     162=== Code generation === 
     164For the last two years we have been advertising a major upheaval in 
     165GHC's back end.  Currently a monolithic "code generator" converts 
     166lambda code (the STG language) into flat `C--`; "flat" in the sense 
     167that the stack is manifested, and there are no function calls. 
     168The upheaval splits this in to a pipeline of passes, with a relatively-simple 
     169conversion of lambda code into `C--` (with function calls), followed 
     170by a succession of passes that optimise this code, and flatten it 
     171(by manifesting the stack and removing calls). 
     173John Dias is the principal architect of this new path, and it is in GHC 
     174already; you can switch it on by saying `-fnew-codegen`.  What remains is 
     175(a) to make it work 100% (currently 99%, which is not good enough); (b) 
     176commit to it, which will allow us to remove gargantuan quantities of 
     177cruft; (c) exploit it, by implementing cool new optimisations at the `C--` level; 
     178(d) take it further by integrating the native code generators into the  
     179same pipeline.  You can read more on the wiki [CodeGen]. 
     181Several passes of the new code generation pipeline are supported by Hoopl, 
     182a Haskell library that makes it easy to write dataflow analyses and optimisations 
     183over `C--` code [Hoopl].  We think Hoopl is pretty cool, and have well-advanced 
     184ideas for how to improve it a lot more. 
     186All of this has taken longer than we hoped.  Once the new pipeline is in place 
     187we hope that others will join in.  For example, David Terei did an interesting 
     188undergraduate project on using LLVM as a back end for GHC [Terei], and  
     189Krzysztof Wos is just beginning an undergraduate project on optimisation in the new pipeline. 
     190We are particularly grateful to Ben Lippmeier for his work on the SPARC native code generator. 
     193== References == 
     195[Platforms]  '''A wiki ref''' 
     197[IHG]  Industrial Haskell Group  
     200[UM]   GHC 6.12 user manual  
     203[BuildSystem] '''A wiki ref''' 
     205[ICFP09] "Complete and Decidable Type Inference for GADTs", Tom Schrijvers,  
     206Simon Peyton Jones, Martin Sulzmann, and Dimitrios Vytiniotis. ICFP'09.  
     209[LetGen] "Let should not be generalised", Dimitrios Vytiniotis, Simon 
     210Peyton Jones, and Tom Schrijvers, submitted to TLDI'10.  
     213[Hoopl] "Hoopl: dataflow optimisation made simple", Norman Ramsey, John Dias, and Simon Peyton Jones,  
     214rejected by POPL 2010. 
     217[Terei] '''Manuel: what URL?''' 
     219[MaxB] "Types are calling conventions", Max Bolingbroke and Simon Peyton Jones, Haskell Symposium 2009. 
     222[InlinePatch] The big INLINE patch [] 
     224[NeilM] "Transformation and Analysis of Functional Programs", Neil Mitchelll,  
     225PhD thesis, University of York, 2009.  
     228[PeterJ] "Positive supercompliation for a higher order call-by-value language",  
     229Peter Jonsson and Johan Nordlander, POPL 2009. 
     232[Annotations] '''A wiki ref''' 
     234[CodeGen] '''A wiki ref'''