Changes between Version 37 and Version 38 of Status/GHC-6.12
- Jun 30, 2009 1:43:31 PM (6 years ago)
v37 v38 1 = Plans for GHC 6.10= 1 = = 2 2 3 We expect to release GHC 6.10 around ICFP 2008. 3 As usual, we're planning a major release of GHC around September. 4 Here's our list of the main items currently scheduled for 6.12.1, and 5 their status. If you have the time and inclination to help with any of 6 these, please get involved! 4 7 5 * [http://www.haskell.org/pipermail/glasgow-haskell-users/2008-September/015539.html 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. 6 11 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 <[email protected]>. 8 17 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. 15 21 16 * '''Parallel garbage collection''' (see [http://research.microsoft.com/%7Esimonpj/papers/parallel-gc/index.htm 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? 17 25 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? 19 28 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? 21 31 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. 23 36 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. 37 The smaller items are all embodied in tickets, here are the tickets 38 currently in the 6.12.1 milestone (135): 39 * http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.12.1 40 and on the 6.12 branch (251): 41 * http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.12+branch 27 42 28 * '''Haddock 2''' 29 * Build it with GHC (maybe ship it with GHC too) 30 * Documentation for GHC API done via Haddock 2 43 I estimate there are 2 man years of work here - needless to say, we 44 aren't going to fix all these tickets :) As usual, if you want to vote 45 for something, add your email to the CC field of the ticket. 31 46 32 * '''Extensible exceptions''', along the lines of Simon's paper [http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf "An Extensible Dynamically-Typed Hierarchy of Exceptions"]. This is mainly a library change. 47 Several of these tickets would make good tasks for a fledgling GHC 48 hacker. e.g. http://hackage.haskell.org/trac/ghc/ticket/2362 (allow 49 full import syntax in GHCi) has a lot of support, and is a nice 50 self-contained task (but not a small one). 33 51 34 * '''Haddock 2''' (see also #1964 (GHC.Prim)). ('''Ian Lynagh''') 52 Even if you're not a GHC hacker you can still help, e.g. by helping to 53 narrow down the cause of a bug, or verifying a bug on your platform. 35 54 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. 37 38 * '''[http://haskell.org/haskellwiki/GHC/Indexed_types Type families]''', fully working. ''Manuel Chakravarty and Simon PJ'' 39 40 * '''[http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell Nested data parallelism]''', in some form. ''Roman Leshchinskiy, Gabriele Keller, Manuel Chakravarty, Simon PJ'' 41 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. 43 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. 45 46 == Things we plan to do for sure == 47 48 * '''Ship the Haskell Library Platform''' instead of 'extralibs'. '''Don and Duncan''' are leading. 49 50 = Beyond 6.10 = 51 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. 53 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. 55 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. 59 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 65 66 67 * '''Opaque interfaces''' (optionally), so you can upgrade a library without recompiling. 68 69 * '''Parallelism'': better profiling tools. 70 71 * '''Visual Haskell''': a Visual Studio plugin. There is one, but it has suffered bit-rot. 72 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. 74 75 * '''Static verification''' along the lines of Dana Xu's work. 76 77 * '''Finish System.Process revamp''' (#2233) 78 79 * Binary package DB, or at least make the one-file-per package work (#593, #723, #2089) 55 Let me remind people that GHC HEAD has the new build system, and it's 56 actually rather pleasant to work with. Even if you have no idea what 57 you're doing, you can always say 'make' at the top level and the build 58 system will figure out what needs doing (ok, so that's what build 59 systems are supposed to do, but GHC's has never quite managed it until 60 now!).