Changes between Version 37 and Version 38 of Status/GHC-6.12

Jun 30, 2009 1:43:31 PM (8 years ago)



  • Status/GHC-6.12

    v37 v38  
    1 = Plans for GHC 6.10 =
     1= Release plans for GHC 6.12 =
    3 We expect to release GHC 6.10 around ICFP 2008. 
     3As usual, we're planning a major release of GHC around September.
     4Here's our list of the main items currently scheduled for 6.12.1, and
     5their status.  If you have the time and inclination to help with any of
     6these, please get involved!
    5  *  [ Beta released].
     8 * Parallel performance.  6.12.1 will ship with the improvements to
     9 parallel performance described in our ICFP 2009 paper.  Still to do:
     10 overhaul the +RTS GC settings, tune for good performance by default.
    7 == Things that are done already ==
     12 * Parallel profiling: the new RTS tracing features will be included, and
     13 we hope to have a release of `ThreadScope` to coincide with GHC 6.12.1.
     14 `ThreadScope` is written using gtk2hs, and could benefit from someone with
     15 expertise in producing polished gtk2hs apps - if you can lend a hand,
     16 contact Satnam Singh <>.
    9  * Several '''language extensions''' advertised in the [wiki:Status/Nov07 November 2007 status report]:
    10    * Improvements to record syntax
    11    * View patterns
    12    * Quasiquotation
    13    * Generalised list comprehensions
    14  '''Done''': these are all in the HEAD already.
     18 * Unicode I/O: the new Unicode I/O library is in, and will ship with
     19 6.12.1.  Still to do: decide on the public API for changing encodings
     20 and newline conversion.
    16  * '''Parallel garbage collection''' (see [ Parallel generational-copying garbage collection with a block-structured heap]).  '''Done'''.
     22 * Shared libraries: we intend to ship with shared library support on at
     23 least x86/Linux and x86-64/Linux.  There are various tasks remaining to
     24 do here - Duncan, can we have a summary?
    18  * '''External Core''' (output only) is working again, thanks to Tim Chevalier.
     26 * Data Parallel Haskell.  Manuel, can you comment on the state of play?
     27   What can we expect in time for 6.12.1?
    20  * Better '''versioning''' to support separate compilation based on MD5 fingerprints. Already done (and documented! see [wiki:Commentary/Compiler/RecompilationAvoidance].
     29 * Plugin support in GHC.  The patches are not yet in GHC, and as far as
     30 I know are awaiting review - Simon, can you say more?
    22  * GHC now uses '''libffi''' to implement parts of the FFI, replacing some of the home-grown and very architecture-specific code we had to do this.  Amongst other benefits, this will ease the task of porting GHC in the future. Done; but ''maybe use it to solve the SE Linux paranoia problem?''
     32 * The new backend code generator.  At the moment, it seems unlikely that
     33 GHC 6.12.1 will ship with the new code generator enabled by default,
     34 although it may well be available for testing.  Meanwhile, work on it
     35 continues.
    24  * '''Backwards compatibility''': we've introduce "base3-compat", a backwards-compatible version of the base library
    25    that will provide essentially the same API as the base library that shipped with GHC 6.8.3, so that code
    26    depending on base-3 will continue to just work.
     37The smaller items are all embodied in tickets, here are the tickets
     38currently in the 6.12.1 milestone (135):
     39 *
     40and on the 6.12 branch (251):
     41 *
    28  * '''Haddock 2'''
    29     * Build it with GHC (maybe ship it with GHC too)
    30     * Documentation for GHC API done via Haddock 2
     43I estimate there are 2 man years of work here - needless to say, we
     44aren't going to fix all these tickets :)  As usual, if you want to vote
     45for something, add your email to the CC field of the ticket.
    32  * '''Extensible exceptions''', along the lines of Simon's paper [ "An Extensible Dynamically-Typed Hierarchy of Exceptions"].  This is mainly a library change.
     47Several of these tickets would make good tasks for a fledgling GHC
     48hacker.  e.g. (allow
     49full import syntax in GHCi) has a lot of support, and is a nice
     50self-contained task (but not a small one).
    34  * '''Haddock 2''' (see also #1964 (GHC.Prim)).  ('''Ian Lynagh''')
     52Even if you're not a GHC hacker you can still help, e.g. by helping to
     53narrow down the cause of a bug, or verifying a bug on your platform.
    36  * '''GHC API''' improvement: '''Thomas Schilling''' is doing a SoC project.  Preserve comments and pragmas, generic traversals (#1467, #1886, GhcApiStatus). We'll ship whatever Thomas has committed by then.
    38  * '''[ Type families]''', fully working. ''Manuel Chakravarty and Simon PJ''
    40  * '''[ Nested data parallelism]''', in some form. ''Roman Leshchinskiy, Gabriele Keller, Manuel Chakravarty, Simon PJ''
    42   * More library reorg (#1338).  The goal here is to shift stuff out of boot-libs and into the Haskell Library Platform, which is independently upgradable.  Not hugely urgent, nice to have.
    44   * `^C` should raise an exception by default (also SIGPIPE, see #1619, #2301). Nearly done!  But not quite complete if you fork another process.  This latter part is lower priority.
    46 == Things we plan to do for sure ==
    48   * '''Ship the Haskell Library Platform''' instead of 'extralibs'.  '''Don and Duncan''' are leading.
    50 = Beyond 6.10 =
    52 This is a list of things that are floating about in our minds for what to do beyond 6.10.  Nothing is decided, and these items vary wildly in their size.
    54  * '''[wiki:Commentary/Compiler/NewCodeGen Back-end revamp]''' (see also #1501).  '''John Dias''' is in charge.  For 6.10 we will make sure that the whole existing path still exists, so we can choose at a late date whether to rely on the new path or not.
    56  * '''Unicode support for text I/O'''.  This means adding Unicode encoding/decoding for Text I/O handles.   ('''Simon Marlow''': a few days work.)
    57    * Consensus was that Text I/O should always use the current locale encoding. 
    58    * You can elect to have no encoding by opening in binary mode, but that's all.
    60  * '''Shared libraries''', as a result of Clemens Fruhwirth's Summer of Code project.  (#1876) '''Simon Marlow''': about a week's work.
    61    * Binaries get much smaller
    62    * Compile a package on Windows to a DLL; it just works
    63    * C program (or Excel) that calls multiple Haskell functions gets just one copy of the RTS, rather than one per DLL as now.
    64    * Performance penalty, but too small to measure
    67  * '''Opaque interfaces''' (optionally), so you can upgrade a library without recompiling.
    69  * '''Parallelism'': better profiling tools.
    71  * '''Visual Haskell''': a Visual Studio plugin.  There is one, but it has suffered bit-rot.
    73  * '''GHC as a platform''' is the aspiration that it should be easy to plug extensions into GHC, and easy to use GHC to extend other software.
    75  * '''Static verification''' along the lines of Dana Xu's work.
    77  * '''Finish System.Process revamp''' (#2233)
    79  * Binary package DB, or at least make the one-file-per package work (#593, #723, #2089)
     55Let me remind people that GHC HEAD has the new build system, and it's
     56actually rather pleasant to work with.  Even if you have no idea what
     57you're doing, you can always say 'make' at the top level and the build
     58system will figure out what needs doing (ok, so that's what build
     59systems are supposed to do, but GHC's has never quite managed it until