|Version 16 (modified by simonpj, 8 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.
- Haddock 2 (see also #1964 (GHC.Prim), #2335 (build problem)). (Ian Lynagh: a few days.)
- Build it with GHC (maybe ship it with GHC too)
- Documentation for GHC API done via Haddock 2
- Unicode support for text I/O. This means adding Unicode encoding/decoding for Text I/O handles. (Simon Marlow: a few days work.)
- Consensus was that Text I/O should always use the current locale encoding.
- You can elect to have no encoding by opening in binary mode, but that's all.
- Extensible exceptions, along the lines of Simon's paper An Extensible Dynamically-Typed Hierarchy of Exceptions. This is mainly a library change. Ian Lynagh is running a discussion, but we expect it to reach consensus in plenty of time for 6.10.
- 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. (#1876) Simon Marlow
- Binaries get much smaller
- Compile a package on Windows to a DLL; it just works
- C program (or Excel) that calls multiple Haskell functions gets just one copy of the RTS, rather than one per DLL as now.
- Performance penalty, but too small to measure
- 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.
- Type families, fully working. Manuel Chakravarty and Simon PJ
- Nested data parallelism, in some form. Roman Leshchinskiy, Gabriele Keller, Manuel Chakravarty, Simon PJ
- Further library reorganisation, but with more attention paid to backward compatibility. Ian Lynagh
- Better versioning to support separate compilation; perhaps checksums/fingerprints. Already done!
- 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
- backwards compat
- 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.