|Version 8 (modified by simonmar, 6 years ago) (diff)|
Plans for 6.8.3
Here are our release plans for 6.8.3
Plans for GHC 6.10
We expect to release GHC 6.10 around ICFP 2008. Here are the big items that we hope to include, along with who is primarily responsible for delivering these promises:
- Several language extensions advertised in the November 2007 status report:
- Improvements to record syntax
- View patterns
- Generalised list comprehensions
These are all in the HEAD already.
- External Core (output only) is working again, thanks to Tim Chevalier.
- Extensible exceptions, along the lines of Simon's paper An Extensible Dynamically-Typed Hierarchy of Exceptions. This is mainly a library change. Simon Marlow
- Parallel garbage collection (see Parallel generational-copying garbage collection with a block-structured heap). Simon Marlow
- Shared libraries, as a result of Clemens Fruhwirth's Summer of Code project. Simon Marlow
- Type families, fully working. Manuel Chakravarty and Simon PJ
- Nested data parallelism, in some form. Roman Leshchinskiy, Gabriele Keller, Manuel Chakravarty, Simon PJ
- Substantial changes to the back end are likely, now that John Dias is here as an intern.n John Dias, Simon PJ, Norman Ramsey
- Further library reorganisation, but with more attention paid to backward compatibility. Ian Lynagh
- Better versioning to support separate compilation; perhaps checksums/fingerprints.
- Improvements to the GHC API (Thomas Schilling's SoC project)
- 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.
Temporary list of 6.10 priorities
- Back-end revamp, remove mangler (see also #1501)
- shared libraries (#1876)
- Haddock 2 (see also #1964 (GHC.Prim), #2335 (build problem))
- encoding/decoding for Text I/O handles. Consensus was that Text I/O should always use the current locale encoding.
- backwards compat
- extensible exceptions
- more library reorg (#1338)
- binary package DB, or at least make the one-file-per package work (#593, #723, #2089)
- C should raise an exception by default (also SIGPIPE, see #1619, #2301)
- initial GHC API improvements: preserve comments and pragmas, generic traversals (#1467, #1886, GhcApiStatus)
- include cabal-install in the release (#2385)
- finish System.Process revamp (#2233)
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.
- Opaque interfaces (optionally), so you can upgrade a library without recompiling.
- Parallelism: better profiling tools.
- Visual Haskell: a Visual Studio plugin. There is one, but it has suffered bit-rot.
- 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.
- Static verification along the lines of Dana Xu's work.