4. Release notes for version 8.10.1¶

The significant changes to the various parts of the compiler are listed in the following sections.

4.1. Highlights¶

The UnliftedNewtypes extension.

4.2. Full details¶

4.2.1. Language¶

Kind variables are no longer implicitly quantified when an explicit forall is used, see GHC proposal #24. -Wimplicit-kind-vars is now obsolete.

Kind variables are no longer implicitly quantified in constructor declarations:

data T a        = T1 (S (a :: k)) | forall (b::k). T2 (S b)  -- no longer accepted
data T (a :: k) = T1 (S (a :: k)) | forall (b::k). T2 (S b)  -- still accepted

Implicitly quantified kind variables are no longer put in front of other variables:

f :: Proxy (a :: k) -> Proxy (b :: j)

ghci> :t +v f   -- old order:
f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b

ghci> :t +v f   -- new order:
f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b

This is a breaking change for users of TypeApplications.

In type synonyms and type family equations, free variables on the RHS are no longer implicitly quantified unless used in an outermost kind annotation:

type T = Just (Nothing :: Maybe a)         -- no longer accepted
type T = Just Nothing :: Maybe (Maybe a)   -- still accepted

A new extension StandaloneKindSignatures allows one to explicitly specify the kind of a type constructor, as proposed in GHC proposal #54:
```
type TypeRep :: forall k. k -> Type
data TypeRep a where
  TyInt   :: TypeRep Int
  TyMaybe :: TypeRep Maybe
  TyApp   :: TypeRep a -> TypeRep b -> TypeRep (a b)
```
Analogous to function type signatures, a standalone kind signature enables polymorphic recursion. This feature is a replacement for CUSKs.
GHC now parses visible, dependent quantifiers (as proposed in GHC proposal 35), such as the following:
```
data Proxy :: forall k -> k -> Type
```
See the section on explicit kind quantification for more details.
Type variables in associated type family default declarations can now be explicitly bound with a forall when ExplicitForAll is enabled, as in the following example:
```
class C a where
  type T a b
  type forall a b. T a b = Either a b
```
This has a couple of knock-on consequences:
- Wildcard patterns are now permitted on the left-hand sides of default declarations, whereas they were rejected by previous versions of GHC.
- It used to be the case that default declarations supported occurrences of left-hand side arguments with higher-rank kinds, such as in the following example:
```
class C a where
  type T a (f :: forall k. k -> Type)
  type T a (f :: forall k. k -> Type) = f Int
```
  This will no longer work unless f is explicitly quantified with a forall, like so:
```
class C a where
  type T a (f :: forall k. k -> Type)
  type forall a (f :: forall k. k -> Type).
       T a f = f Int
```
A new extension UnliftedNewtypes that relaxes restrictions around what kinds of types can appear inside of the data constructor for a newtype. This was proposed in GHC proposal #13.
A new extension ImportQualifiedPost allows the syntax import M qualified, that is, to annotate a module as qualified by writing qualified after the module name. This was proposed in GHC proposal #49.
New flag -Wderiving-defaults that controls a warning message when both DeriveAnyClass and GeneralizedNewtypeDeriving are enabled and no explicit deriving strategy is in use. The warning is enabled by default and has been present in earlier GHC versions but without the option of disabling it. For example, this code would trigger the warning:
```
class C a
newtype T a = MkT a deriving C
```
GHC now performs more validity checks on inferred type signatures. One consequence of this change is that some programs that used to be accepted will no longer compile without enabling the required language extensions. For example, in these two modules:
```
{-# LANGUAGE RankNTypes #-}
module A where

  foo :: (forall a. a -> a) -> b -> b
  foo f x = f x

module B where

  import A

  bar = foo
```
Notice that A enables -XRankNTypes, but B does not. Previous versions of GHC would allow bar to typecheck, even though its inferred type is higher-rank. GHC 8.10 will now reject this, as one must now enable -XRankNTypes in B to accept the inferred type signature.
Type family dependencies (also known as injective type families) sometimes now need -XUndecidableInstances in order to be accepted. Here is an example:
```
type family F1 a = r | r -> a
type family F2 a = r | r -> a
type instance F2 [a] = Maybe (F1 a)
```
Because GHC needs to look under a type family to see that a is determined by the right-hand side of F2‘s equation, this now needs -XUndecidableInstances. The problem is very much akin to its need to detect some functional dependencies.

4.2.2. Compiler¶

Add new flags -Wunused-record-wildcards and -Wredundant-record-wildcards which warn users when they have redundant or unused uses of a record wildcard match.
Calls to memset and memcpy are now unrolled more aggressively and the produced code is more efficient on x86-64 with added support for 64-bit MOVs. In particular, setByteArray# and copyByteArray# calls that were not optimized before, now will be. See #16052.
GHC’s runtime linker no longer uses global state. This allows programs that use the GHC API to safely use multiple GHC sessions in a single process, as long as there are no native dependencies that rely on global state.
When loading modules that use UnboxedTuples or UnboxedSums into GHCi, it will now automatically enable -fobject-code for these modules and all modules they depend on. Before this change, attempting to load these modules into the interpreter would just fail, and the only convenient workaround was to enable -fobject-code for all modules. See the GHCi FAQ for further details.
The eventlog now contains events for biographical and retainer profiling. The biographical profiling events all appear at the end of the eventlog but the sample start event contains a timestamp of when the census occurred. The retainer profiling events are emitted using the standard events.
The eventlog now records the cost centre stack on each profiler sample. This enables the .prof file to be partially reconstructed from the eventlog.
Add new flag -fkeep-going which makes the compiler continue as far as it can despite errors.
Deprecated flag -fwarn-hi-shadowing because it was not implemented correctly, and appears to be largely unused. This flag will be removed in a later version of GHC.
Windows bindist has been updated to GCC 9.2 and binutils 2.32. These binaries have been patched to no longer have have the MAX_PATH limit. Windows users should no longer have any issues with long path names.
Introduce DynFlags plugins, that allow users to modidy the DynFlags that GHC is going to use when processing a set of files, from plugins. They can be used for applying tiny configuration changes, registering hooks and much more. See the user guide for more details as well as an example.

4.2.3. GHCi¶

Added a command :instances to show the class instances available for a type.
Added new debugger commands :disable and :enable to disable and re-enable breakpoints.
Improved command name resolution with option !. For example, :k! resolves to :kind!.

4.2.4. Runtime system¶

The runtime system linker now marks loaded code as non-writable (see #14069) on all tier-1 platforms. This is necesaary for out-of-the-box compatibility with OpenBSD and macOS Catalina (see #17353)

4.2.5. Template Haskell¶

The Lift typeclass is now levity-polymorphic and has a liftTyped method. Previously disallowed instances for unboxed tuples, unboxed sums, an primitive unboxed types have also been added. Finally, the code generated by DeriveLift has been simplified to take advantage of expression quotations.
Using TupleT 1, TupE [exp], or TupP [pat] will now produce unary tuples (i.e., involving the Unit type from GHC.Tuple) instead of silently dropping the parentheses. This brings Template Haskell’s treatment of boxed tuples in line with that of unboxed tuples, as UnboxedTupleT`, ``UnboxedTupE, and UnboxedTupP also produce unary unboxed tuples (i.e., Unit#) when applied to only one argument.
GHC’s constraint solver now solves constraints in each top-level group sooner. This has practical consequences for Template Haskell, as TH splices necessarily separate top-level groups. For example, the following program would compile in previous versions of GHC, but not in GHC 8.10:
```
data T = MkT

tStr :: String
tStr = show MkT

$(return [])

instance Show T where
  show MkT = "MkT"
```
This is because each top-level group’s constraints are solved before moving on to the next, and since the top-level group for tStr appears before the top-level group that defines a Show T instance, GHC 8.10 will throw an error about a missing Show T instance in the expression show MkT. The issue can be fixed by rearranging the order of declarations. For instance, the following will compile:
```
data T = MkT

instance Show T where
  show MkT = "MkT"

$(return [])

tStr :: String
tStr = show MkT
```

4.2.6. `ghc-prim` library¶

Add new bitReverse# primops that, for a Word of 8, 16, 32 or 64 bits, reverse the order of its bits e.g. 0b110001 becomes 0b100011. These primitives use optimized machine instructions when available.

4.2.7. `ghc` library¶

4.2.8. `base` library¶

4.2.9. Build system¶

Countless bug fixes in the new Hadrian build system
Hadrian now supports a simple key-value configuration language, eliminating the need for users to use Haskell to define build configuration. This should simplify life for packagers and users alike. See #16769 and the documentation in hadrian/doc/user-settings.md.

4.3. Included libraries¶

The package database provided with this distribution also contains a number of packages other than GHC itself. See the changelogs provided with these packages for further change information.

Package	Version	Reason for inclusion
ghc	8.10.0.20191210	The compiler itself
Cabal	3.1.0.0	Dependency of `ghc-pkg` utility
Win32	2.6.1.0	Dependency of `ghc` library
array	0.5.4.0	Dependency of `ghc` library
base	4.14.0.0	Core library
binary	0.8.7.0	Dependency of `ghc` library
bytestring	0.10.9.0	Dependency of `ghc` library
containers	0.6.2.1	Dependency of `ghc` library
deepseq	1.4.4.0	Dependency of `ghc` library
directory	1.3.4.0	Dependency of `ghc` library
filepath	1.4.2.1	Dependency of `ghc` library
ghc-boot-th	8.10.0.20191210	Internal compiler library
ghc-boot	8.10.0.20191210	Internal compiler library
ghc-compact	0.1.0.0	Core library
ghc-heap	8.10.0.20191210	GHC heap-walking library
ghc-prim	0.6.1	Core library
ghci	8.10.0.20191210	The REPL interface
haskeline	0.8.0.0	Dependency of `ghci` executable
hpc	0.6.0.3	Dependency of `hpc` executable
integer-gmp	1.0.2.0	Core library
libiserv	8.10.0.20191210	Internal compiler library
mtl	2.2.2	Dependency of `Cabal` library
parsec	3.1.14.0	Dependency of `Cabal` library
pretty	1.1.3.6	Dependency of `ghc` library
process	1.6.6.0	Dependency of `ghc` library
stm	2.5.0.0	Dependency of `haskeline` library
template-haskell	2.16.0.0	Core library
terminfo	0.4.1.4	Dependency of `haskeline` library
text	1.2.3.1	Dependency of `Cabal` library
time	1.9.3	Dependency of `ghc` library
transformers	0.5.6.2	Dependency of `ghc` library
unix	2.7.2.2	Dependency of `ghc` library
xhtml	3000.2.2.1	Dependency of `haddock` executable

Glasgow Haskell Compiler User's Guide

Table Of Contents

Previous topic

Next topic

This Page

4. Release notes for version 8.10.1¶

4.1. Highlights¶

4.2. Full details¶

4.2.1. Language¶

4.2.2. Compiler¶

4.2.3. GHCi¶

4.2.4. Runtime system¶

4.2.5. Template Haskell¶

4.2.6. `ghc-prim` library¶

4.2.7. `ghc` library¶

4.2.8. `base` library¶

4.2.9. Build system¶

4.3. Included libraries¶

Glasgow Haskell Compiler User's Guide

4. Release notes for version 8.10.1¶

4.1. Highlights¶

4.2. Full details¶

4.2.1. Language¶

4.2.2. Compiler¶

4.2.3. GHCi¶

4.2.4. Runtime system¶

4.2.5. Template Haskell¶

4.2.6. ghc-prim library¶

4.2.7. ghc library¶

4.2.8. base library¶

4.2.9. Build system¶

4.3. Included libraries¶

4.2.6. `ghc-prim` library¶

4.2.7. `ghc` library¶

4.2.8. `base` library¶