... | @@ -6,15 +6,15 @@ GHC development is as busy as ever, and 7.10 is going to be no different. Our cu |
... | @@ -6,15 +6,15 @@ GHC development is as busy as ever, and 7.10 is going to be no different. Our cu |
|
|
|
|
|
However, we still need help with it all. GHC is a community project, and as you may be aware, most of this is done by our wonderful contributors. If you want something done, you should certainly try to get in touch and help make it a reality!
|
|
However, we still need help with it all. GHC is a community project, and as you may be aware, most of this is done by our wonderful contributors. If you want something done, you should certainly try to get in touch and help make it a reality!
|
|
|
|
|
|
## Plans for 7.10
|
|
## Upcoming plans for the next year
|
|
|
|
|
|
## Libraries, source language, type system
|
|
## Libraries, source language, type system
|
|
|
|
|
|
- **Applicative is now a superclass of Monad**. After much debate, in GHC 7.10, Applicative is finally a superclass of `Monad`, hence completing the Applicative Monad Proposal.
|
|
- **Applicative is now a superclass of Monad**. After much debate, in GHC 7.10, Applicative is finally a superclass of `Monad`, hence completing the Applicative Monad Proposal.
|
|
|
|
|
|
- **BBP: Foldable/Traversable**. As part of the so-called "Burning-Bridges Proposal", the monomorphic definitions in `Prelude`/`Data.List`/`Control.Monad` that conflict with those from `Data.Foldable` and `Data.Traversable` have been replaced by their respective ones from `Data.Foldable`/`Data.Traversable`
|
|
- **BBP: Foldable/Traversable**. As part of the so-called "Burning-Bridges Proposal", the monomorphic definitions in `Prelude`/`Data.List`/`Control.Monad` that conflict with those from `Data.Foldable` and `Data.Traversable` have been replaced by their respective ones from `Data.Foldable`/`Data.Traversable`. This will be in 7.10
|
|
|
|
|
|
- **Signature sections**. Lennart Augustsson is implementing `(:: ty)` to work the same as `(\x -> x :: ty)`. Needs a wiki design page.
|
|
- **Signature sections**. Lennart Augustsson is implementing `(:: ty)` to work the same as `(\x -> x :: ty)`.
|
|
|
|
|
|
- **[ApplicativeDo](applicative-do)** - Now that `Applicative` is a superclass of `Monad`, Simon Marlow has plans to implement a new extension for GHC, which will allow `do` notation to be used in the context of `Applicative`, not just `Monad`.
|
|
- **[ApplicativeDo](applicative-do)** - Now that `Applicative` is a superclass of `Monad`, Simon Marlow has plans to implement a new extension for GHC, which will allow `do` notation to be used in the context of `Applicative`, not just `Monad`.
|
|
|
|
|
... | @@ -28,15 +28,15 @@ However, we still need help with it all. GHC is a community project, and as you |
... | @@ -28,15 +28,15 @@ However, we still need help with it all. GHC is a community project, and as you |
|
|
|
|
|
- **Kind equality and kind coercions** - Richard Eisenberg (with support from Simon PJ and Stephanie Weirich, among others) is implementing a change to the Core language, as described in a recent paper [ FC](http://www.seas.upenn.edu/~eir/papers/2013/fckinds/fckinds-extended.pdf). When this work is complete, *all* types will be promotable to kinds, and *all* data constructors will be promotable to types. This will include promoting type synonyms and type families. As the details come together, there may be other source language effects, such as the ability to make kind variables explicit. It is not expected for this to be a breaking change -- the change should allow strictly more programs to be accepted.
|
|
- **Kind equality and kind coercions** - Richard Eisenberg (with support from Simon PJ and Stephanie Weirich, among others) is implementing a change to the Core language, as described in a recent paper [ FC](http://www.seas.upenn.edu/~eir/papers/2013/fckinds/fckinds-extended.pdf). When this work is complete, *all* types will be promotable to kinds, and *all* data constructors will be promotable to types. This will include promoting type synonyms and type families. As the details come together, there may be other source language effects, such as the ability to make kind variables explicit. It is not expected for this to be a breaking change -- the change should allow strictly more programs to be accepted.
|
|
|
|
|
|
- **Partial type signatures** - Thomas Winant and Dominique Devriese are working on partial type signatures for GHC. A partial type signature is a type signature that can contain *wildcards*, written as underscores. These wildcards can be types unknown to the programmer or types he doesn't care to annotate. The type checker will use the annotated parts of the partial type signature to type check the program, and infer the types for the wildcards. A wildcard can also occur at the end of the constraints part of a type signature, which indicates that an arbitrary number of extra constraints may be inferred. Whereas `-XTypedHoles` allow holes in your terms, `-XPartialTypeSignatures` allow holes in your types. The design as well as a working implementation are currently being simplified [PartialTypeSignatures](partial-type-signatures).
|
|
- **Partial type signatures** - Thomas Winant and Dominique Devriese are working on partial type signatures for GHC. A partial type signature is a type signature that can contain *wildcards*, written as underscores. These wildcards can be types unknown to the programmer or types he doesn't care to annotate. The type checker will use the annotated parts of the partial type signature to type check the program, and infer the types for the wildcards. A wildcard can also occur at the end of the constraints part of a type signature, which indicates that an arbitrary number of extra constraints may be inferred. Whereas `-XTypedHoles` allow holes in your terms, `-XPartialTypeSignatures` allow holes in your types. The design as well as a working implementation are currently being simplified [PartialTypeSignatures](partial-type-signatures). This will
|
|
|
|
|
|
- **Binary literals** ([\#9224](https://gitlab.haskell.org//ghc/ghc/issues/9224)) - Herbert Valerio Riedel implemented the `-XBinaryLiterals` language extension which finally closes the syntax gap relative to other languages which allow to write base-2 literals such as `0b11001001`.
|
|
- **Binary literals** ([\#9224](https://gitlab.haskell.org//ghc/ghc/issues/9224)) - Herbert Valerio Riedel implemented the `-XBinaryLiterals` language extension which finally closes the syntax gap relative to other languages which allow to write base-2 literals such as `0b11001001`. This is in GHC 7.10.
|
|
|
|
|
|
- **Propositional equality for `GHC.Generics` metadata** - Gabor Greif is working on a conservative approach to retrofit the metadata types generated by `-XDeriveGeneric` with a runtime-observable type equality. The feature is discussed under [GenericsPropositionalEquality](generics-propositional-equality).
|
|
- **Propositional equality for `GHC.Generics` metadata** - Gabor Greif is working on a conservative approach to retrofit the metadata types generated by `-XDeriveGeneric` with a runtime-observable type equality. The feature is discussed under [GenericsPropositionalEquality](generics-propositional-equality).
|
|
|
|
|
|
- **Backpack module system** - Edward Yang is working on extensions to GHC and Cabal to support Backpack. Details in the [Backpack wiki page](backpack). At the moment, module reexports, the package key infrastructure change, and module thinning and renaming are in GHC HEAD and definitely shipping with 7.10; signatures and Cabal support are coming down the pike.
|
|
- **Backpack module system** - Edward Yang is working on extensions to GHC and Cabal to support Backpack. Details in the [Backpack wiki page](backpack). At the moment, module reexports, the package key infrastructure change, and module thinning and renaming are in GHC HEAD and definitely shipping with 7.10; signatures and Cabal support are coming down the pike. This is in GHC 7.10.
|
|
|
|
|
|
- **More list fusion** - Based on a new compiler transformation by Joachim Breitner, [CallArity](call-arity), `foldl` and related functions now can take part in list fusion. David Feuer then came up with fusion rules for many more functions. This change may not be a unambiguous improvement in all cases, so if you find regressions, we’d like to hear about them.
|
|
- **More list fusion** - Based on a new compiler transformation by Joachim Breitner, [CallArity](call-arity), `foldl` and related functions now can take part in list fusion. David Feuer then came up with fusion rules for many more functions. This change may not be a unambiguous improvement in all cases, so if you find regressions, we’d like to hear about them. These changes are all in 7.10.
|
|
|
|
|
|
## Back-end and runtime system
|
|
## Back-end and runtime system
|
|
|
|
|
... | @@ -44,9 +44,9 @@ However, we still need help with it all. GHC is a community project, and as you |
... | @@ -44,9 +44,9 @@ However, we still need help with it all. GHC is a community project, and as you |
|
|
|
|
|
- **Changes to static closures for faster garbage collection** - Edward Yang is working on an overhaul of how static closures represented at runtime to eliminate some expensive memory dereferences in the GC hotpath. The initial results are encouraging: these changes can result in an up to 8% in the runtime of some GC heavy benchmarks, see [\#8199](https://gitlab.haskell.org//ghc/ghc/issues/8199).
|
|
- **Changes to static closures for faster garbage collection** - Edward Yang is working on an overhaul of how static closures represented at runtime to eliminate some expensive memory dereferences in the GC hotpath. The initial results are encouraging: these changes can result in an up to 8% in the runtime of some GC heavy benchmarks, see [\#8199](https://gitlab.haskell.org//ghc/ghc/issues/8199).
|
|
|
|
|
|
- **New, smaller array type** - Johan Tibell has added a new array type, `SmallArray#`, which uses less memory (2 words) than the `Array#` type, at the cost of being more expensive to garbage collect for array sizes larger than 128 elements.
|
|
- **New, smaller array type** - Johan Tibell has added a new array type, `SmallArray#`, which uses less memory (2 words) than the `Array#` type, at the cost of being more expensive to garbage collect for array sizes larger than 128 elements. This is in GHC 7.10.
|
|
|
|
|
|
- **Faster small array allocation** - Johan Tibell has made array allocation of arrays of small, statically know size faster by making it inline with the normal heap check, instead of out-of-line in a separate nursery block.
|
|
- **Faster small array allocation** - Johan Tibell has made array allocation of arrays of small, statically know size faster by making it inline with the normal heap check, instead of out-of-line in a separate nursery block. This is in GHC 7.10
|
|
|
|
|
|
- **DWARF-based stack tracing** - Peter Wortmann and Arash Rouhani (with support from the Simons) are working on enabling GHC to generate and use DWARF debugging information. This should allow us to obtain stack traces and do profiling without the need for instrumentation. The first stages of this work should land in 7.10, but it's not clear if the full feature set will.
|
|
- **DWARF-based stack tracing** - Peter Wortmann and Arash Rouhani (with support from the Simons) are working on enabling GHC to generate and use DWARF debugging information. This should allow us to obtain stack traces and do profiling without the need for instrumentation. The first stages of this work should land in 7.10, but it's not clear if the full feature set will.
|
|
|
|
|
... | | ... | |