The significant changes to the various parts of the compiler are listed in the following sections. There have also been numerous bug fixes and performance improvements over the 7.8 branch.
There is a new extension,
which allows you to create pointers to expressions which
remain valid across processes. This is useful for
referencing higher-order values in distributed
systems. The pointers are created with a new keyword
static as in
x = static ("abc" ++ "123") :: StaticPtr String.
All processes which dereference
x get the
same result, that is, the body of the static form.
Added support for binary integer literals
Simplified rules for implicit quantification. In previous versions of GHC,
it was possible to use the
to quantify over type variables in
type declarations without a
forall quantifier. For example,
data Fun = Fun (Ord a => a -> b) was identical to
data Fun = Fun (forall a b. Ord a => a -> b), while
data Fun = Fun (a -> b) caused a not-in-scope error.
This implicit quantification is now deprecated, and variables
in higher-rank constructors should be quantified with
regardless of whether a class context is present or not.
GHC 7.10 raises a warning (controlled by
-fwarn-context-quantification, enabled by default)
and GHC 7.12 will raise an error. See examples
in GHC documentation.
The change also applies to Template Haskell splices such as
[t|Ord a => a|], which should be written as
[t|forall a. Ord a => a|].
Instance contexts inferred while processing
directives attached to
declarations now forbid equality constraints. This is a regression in
obscure cases, but it will yield better error messages in more common
cases. Users caught by the regression can simply use standalone-deriving,
where you specify the context yourself.
GHC now checks that all the language extensions required for the inferred type signatures are explicitly enabled. This means that if any of the type signatures inferred in your program requires some language extension you will need to enable it. The motivation is that adding a missing type signature inferred by GHC should yield a program that typechecks. Previously this was not the case.
This is a breaking change. Code that used to compile in the
past might fail with an error message requiring some
particular language extension (most likely
-fwarn-tabs warning flag is turned on by
default with this release of GHC. It can be suppressed
either by using
GHC_OPTIONS pragma or by
A new warning flag,
has been added and is turned on with
-Wall. It warns when a module that is
-XTrustworthy is actually
infered as an
-XSafe module. This lets the
module author know that they can tighten their Safe Haskell
bounds if desired.
-fwarn-unsafe that warn if a module was
infered as Safe or Unsafe have been improved to work with
all Safe Haskell module types. Previously, they only worked
for unmarked modules where the compiler was infering the
modules Safe Haskell type. They now work even for modules
-XUnsafe. This is useful either to have
GHC check your assumptions, or to generate a list of
reasons easily why a module is regarded as Unsafe.
For many use cases, the new
-fwarn-trustworthy-safe flag is better
suited than either of these two.
-ddump-core-pipeline flags have been removed.
Many more options have learned to respect the
For example you can use
to produce a
for each file that uses Template Haskell.
This should be much easier to understand on a larger project
than having everything being dumped to stdout.
Compiler plugins (with the
flag) may now modify the behaviour of the constraint
solver, to add new functionality to GHC's
typechecker. See Section 9.3.4, “Typechecker plugins”
for more details.
A new warning flag,
has been added. The behavior is similar to
-fwarn-missing-signatures but GHC will only
flag exported values. This flag takes precedence over
-fwarn-missing-signatures so it can be used
in conjunction with
Added support for generating LINE pragma declarations (Section 7.22.7, “LINE pragma”).
Pred (which stores a type
constraint) is now a synonym for
in order to work with the
extension. This is a breaking change and may require
some rewriting of Template Haskell code.
Pattern splices now work.
reifyInstances now treats unbound type
variables as univerally quantified, allowing lookup of, say,
the instance for
More kind annotations appear in reified types, in order to
disambiguate types that would otherwise be ambiguous in the
PolyKinds. In particular, all
TyVarBndrs are now
KindedTVs. (This does not affect Template
Haskell quotations, just calls to
Various features unsupported in quotations were previously silently ignored. These now cause errors.
Lift instances were added for
many more types: all of the
All Template Haskell datatypes now have
Ppr instances were added for
Two new declaration forms are now supported:
standalone-deriving declarations and generic method
signatures (written using
a class). This means an expansion to the
Template Haskell is now more pedantic about splicing in bogus variable names, like those containing whitespace. If you use bogus names in your Template Haskell code, this may break your program.
The linker API is now thread-safe. The main
user-facing impact of this change is that you must
loadObj or any of the
other linker APIs.
ghc-pkg now respects
--global when modifying packages (e.g.
changing exposed/trust flag or unregistering). Previously,
ghc-pkg would ignore these flags and modify
whichever package it found first on the database stack. To
recover the old behavior, simply omit these flags.
ghc-pkg accepts a
flag which allows a user to override the location of the user package
database. Unlike databases specified using
a user package database configured this way respects
TODO: cover module renaming, thinning, re-export etc
ghc-pkg (and ghc) have dropped support for single-file style package databases. Since version 6.12, ghc-pkg has defaulted to a new database format (using a directory of files, one per package plus a binary cache).
This change will not affect programs and scripts that use
ghc-pkg init to create package databases.
This will affect scripts that create package databases using tricks like
echo "" > package.conf
Such scripts will need to be modified to use
ghc-pkg init, and to delete databases
by directory removal, rather than simple file delete.
Version number XXXXX (was 184.108.40.206)
GHC has had its internal Unicode database for parsing updated to the Unicode 7.0 standard.
Attempting to access a portion of the result of
System.IO.hGetContents that was not yet
read when the handle was closed now throws an exception.
Previously, a lazy read from a closed handle would simply
end the result string, leading to silent or delayed
Many internal functions in GHC related to package IDs have been
renamed to refer to package keys, e.g.
PackageKey, the wired-in names
primPackageId are now
primPackageKey, etc. This reflects a distinction
that we are now making: a package ID is, as before, the user-visible
ID from Cabal
foo-1.0; a package key is now
a compiler-internal entity used for generating linking symbols, and
may not correspond at all to the package ID. In
particular, there may be multiple package keys per
The ghc library no longer depends on the Cabal library. This means that users of the ghc library are no longer forced to use the same version of Cabal as ghc did. It also means that Cabal is freed up to be able to depend on packages that ghc does not want to depend on (which for example may enable improvements to Cabal's parsing infrastructure).