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.
The highlights, since the 7.8 branch, are:
GHC has implemented "The Applicative Monad Proposal",
meaning the Applicative
typeclass
is now a superclass of Monad
. This
is a breaking change and your programs will need to be
updated.
Please see the GHC
7.10 Migration Guide on the GHC wiki.
GHC has implemented the "Burning Bridges Proposal",
meaning that many of the combinators in
Prelude
are now re-exported from
more generic modules (such as
Data.Traversable
), rather than exporting
custom, less-generic versions. This is a change that
may require updates to your program.
Please see the GHC
7.10 Migration Guide on the GHC wiki.
GHC now has support for 'partial type signatures', which give you the ability to add 'holes' to a type signature that the compiler can later infer. For more, see Section 7.15, “Partial Type Signatures”.
The integer-gmp
package has been
completely rewritten from the ground up. The primary
change in this rewrite is that GHC-compiled programs
that link to GMP no longer 'hook' GMP allocation
routines, to create an Integer
on
the raw Haskell heap. Instead,
integer-gmp
now allocates all
memory in Haskell code, and talks to GMP via normal
FFI imports like other C code.
The practical side effect of this is that C libraries which bind to GMP (such as MPFR or FLINT) no longer need careful (or impossible) hacks to be used inside a GHC-compiled program via the FFI; GMP is treated just like any other C library, with no special accomodations.
GHC now has support for plugins which modify the type checker. This allows external users to interface with GHC and write type-checking plugins to solve constraints and equalities generated by the typechecker.
This feature is experimental and will likely change in the future.
GHC now has support for a new extension,
-XStaticPointers
, that allows you
to (de)reference and serialize pointers to known,
closed expressions. This is primarily aimed at making
distributed programming (via interfaces like Cloud
Haskell) easier. For more, see Section 7.21, “Static pointers
”.
This feature is experimental and will likely change in the future.
GHC now has preliminary support for DWARF-based
debugging, when compiling programs with the new
-g
option. This will embed DWARF
information into the module object files, which can
then be read by tools like GDB for backtraces or
single-stepping.
This feature is highly experimental and will likely change in the future, but should still be useful today.
There is a new extension,
StaticPointers,
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 =>
arrow
to quantify over type variables in data
and
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 forall
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 deriving
directives attached to data
and newtype
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
-XTypeFamilies
, -XGADTs
or
-XFlexibleContexts
).
The solvers for both type family reductions and
Coercible
instances have been improved.
This should lead to faster compilation of type-family-heavy
code and more Coercible
instances to be
found. However, some bugs remain: see 'Known Bugs' below.
-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
specifying -fno-warn-tabs
flag.
The new -fdefer-typed-holes
flag turns
typed hole errors into typed hole warnings that produce
runtime errors when evaluated.
The -fno-warn-typed-holes
flag was
repurposed to silence the warnings produced when
-fdefer-typed-holes
is used. As a result,
it is no longer possible to disable typed holes like it was
in GHC 7.8. This only turned a self-explanatory error into
a cryptic parse error and was thus not very useful.
For more details, consult Section 7.14, “Typed Holes” and
Section 7.16, “Deferring type errors to runtime”.
A new warning flag, -fwarn-trustworthy-safe
has been added and is turned on with
-Wall
. It warns when a module that is
compiled with -XTrustworthy
is actually
infered as an -XSafe
module. This lets the
module author know that they can tighten their Safe Haskell
bounds if desired.
The -fwarn-safe
and
-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
marked as -XTrustworthy
or
-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-simpl-phases
and
-ddump-core-pipeline
flags have been removed.
Many more options have learned to respect the -ddump-to-file
.
For example you can use -ddump-to-file
with -ddump-splices
to produce a .dump-splices file
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 -fplugin
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, -fwarn-missing-exported-sigs
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 -Wall
.
A new warning flag, -fwarn-unticked-promoted-constructors
has been added. This flag causes GHC to warn when you use a promoted constructor without using a "tick" preceding its name.
For example:
data Nat = Succ Nat | Zero data Vec n s where Nil :: Vec Zero a Cons :: a -> Vec n a -> Vec (Succ n) a
Will raise two warnings because Zero
and Succ
are not written as 'Zero
and
'Succ
.
This warning is enabled by default in -Wall
mode.
Added the option -dth-dec-file
.
This dumps out a .th.hs file of all Template Haskell
declarations in a corresponding .hs file. The idea is
that application developers can check this into their
repository so that they can grep for identifiers used
elsewhere that were defined in Template Haskell. This
is similar to using -ddump-to-file
with -ddump-splices
but it always
generates a file instead of being coupled to
-ddump-to-file
and only outputs code
that does not exist in the .hs file and a comment for
the splice location in the original fi
It's now possible to use :set
-l{foo}
in GHCi to link against a
foreign library after startup.
Pattern synonyms are now supported in GHCi.
Added support for generating LINE pragma declarations (Section 7.22.7, “LINE pragma”).
The type Pred
(which stores a type
constraint) is now a synonym for Type
,
in order to work with the ConstraintKinds
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 Eq [a]
.
More kind annotations appear in reified types, in order to
disambiguate types that would otherwise be ambiguous in the
presence of PolyKinds
. In particular, all
reified TyVarBndr
s are now
KindedTV
s. (This does not affect Template
Haskell quotations, just calls to reify
.)
Various features unsupported in quotations were previously silently ignored. These now cause errors.
Lift
instances were added for
many more types: all of the IntXX
and WordXX
types, Ratio a
,
()
, Float
, and
Double
.
All Template Haskell datatypes now have
Generic
and Ord
instances.
Ppr
instances were added for Lit
and Loc
.
Two new declaration forms are now supported:
standalone-deriving declarations and generic method
signatures (written using default
in
a class). This means an expansion to the Dec
type.
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
now call initLinker
before
calling loadObj
or any of the
other linker APIs.
ghc-pkg
now respects --user
and --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 --user-package-db
flag which allows a user to override the location of the user package
database. Unlike databases specified using --package-db
,
a user package database configured this way respects
the --user
flag.
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 4.8.0.0 (was 4.7.0.0)
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
failures.
Many internal functions in GHC related to package IDs have been
renamed to refer to package keys, e.g. PackageId
is now PackageKey
, the wired-in names
such as 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
package ID.
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).
Version number 0.4.0.0 (was 0.3.1.0)
The low-level prefetch API exported by
GHC.Prim
(added in GHC 7.8) has
been overhauled to use State#
parameters to serialize and thread state around.
This API is still considered experimental, and will be prone to change.
Version number 0.6.0.2 (was 0.6.0.1)
The hpc
command supports a new
flag, --verbosity=n
, which
controls the verbosity level of subcommands.
Version number 1.0.0.0 (was 0.5.1.0)
The integer-gmp
package has
been completely rewritten to be more efficient and
interoperate more sanely with the GMP
library. Specifically, GHC no longer needs to
'hook' the GMP memory allocators to make
allocations exist on the Haskell heap, a
complication which makes GMP-dependent C libraries
difficult. This means external libraries that use
GMP (such as MPFR or FLINT) can now be trivially
FFI'd to without any complication.
For issues dealing with language changes, please see the GHC 7.10 Migration Guide on the GHC wiki.
On Mac OS X, the -threaded
Garbage
Collector currently suffers from a large performance
penalty due to a lack of system-specific optimization
(issue #7602).
GHC's LLVM backend is currently incompatible with LLVM 3.4 (issue #9929).
GHCi fails to appropriately load
.dyn_o
files (issue #8736).
Not all cases of non-terminating type-level computation (with both
recursive type families and recursive newtypes) are caught. This
means that GHC might hang, but it should do so only when the program
is ill-typed (due to non-terminating type-level features). The bugs
are reported as #7788
and #10139.
There also remain certain obscure scenarios where the solver for
Coercible
instances is known to be still
incomplete. See comments in #10079.