Skip to content

GitLab

Last edited by Vladislav Zavialov
Page history New page

9.0

GHC 9.0.x Migration Guide

This guide summarises the changes you may need to make to your code to migrate from GHC 8.10 to GHC 9.0. This guide complements the GHC 9.0.x release notes which should be consulted as well.

Compiler changes

Simplified subsumption

GHC now implements simplified subsumption, as described in GHC Proposal #287. This change simplifies the type system, and prevents the possiblity of GHC silently changing the semantics of user programs, but it does mean that some libraries may need eta-expansion to typecheck. Here are some examples of specific programs that will no longer work under simplified subsumption and how they can be repaired in a backwards-compatible manner:

Deep skolemisation

Given these definitions:

f :: forall a b. a -> b -> b
g :: (forall p. p -> forall q. q -> q) -> Int

Previous versions of GHC would typecheck the following:

h :: Int
h = g f

This relies on deep skolemisation, which no longer exists under simplified subsumption. As a result, GHC 9.0 will reject h:

 error:
    • Couldn't match type: b0 -> b0
                     with: forall q. q -> q
      Expected: p -> forall q. q -> q
        Actual: p -> b0 -> b0
    • In the first argument of ‘g’, namely ‘f’
      In the expression: g f
      In an equation for ‘h’: h = g f
   |
   | h = g f
   |       ^

To make h work under simplified subsumption, eta expand the argument to g:

h :: Int
h = g (\x -> f x)

The above example uses higher-rank foralls, but a similar scenario exists with higher-rank contexts as well. Given these definitions:

f' :: (Eq a, Eq b) => a -> b -> b
g' :: (Eq p => p -> Eq q => q -> q) -> Int

Previous versions of GHC would typecheck the following:

h' :: Int
h' = g' f'

Again, this relies on deep skolemisation. As a result, GHC 9.0 will reject h':

error:
    • Couldn't match kind ‘Constraint’ with ‘*’
      When matching types
        q0 -> q0 :: *
        Eq q0 :: Constraint
      Expected: p0 -> Eq q0 => q0 -> q0
        Actual: p0 -> (q0 -> q0) -> q0 -> q0
    • In the first argument of ‘g'’, namely ‘f'’
      In the expression: g' f'
      In an equation for ‘h'’: h' = g' f'
  |
  | h' = g' f'
  |         ^^

h' can also be repaired with manual eta expansion:

h' :: Int
h' = g' (\x -> f' x)

Given that the situation with higher-rank contexts mirrors that of higher-rank foralls so closely, we will only provide examples involving higher-rank foralls from here on out.

Deep instantiation

Given this definition:

f :: Int -> forall a. a -> a
f _ x = x

Previous versions of GHC would typecheck the following:

g :: b -> Int -> a -> a
g x = f

This requires deeply instantiating the type of f. Simplified subsumption gets rid of deep instantiation, however, so g will not typecheck on GHC 9.0:

error:
    • Couldn't match type: forall a1. a1 -> a1
                     with: a -> a
      Expected: Int -> a -> a
        Actual: Int -> forall a. a -> a
    • In the expression: f
      In an equation for ‘g’: g x = f
    • Relevant bindings include
        g :: b -> Int -> a -> a (bound at Bug.hs:8:1)
  |
  | g x = f
  |       ^

There are two possible ways to migrate this code:

  1. Change the type of g to have a nested forall:

    g :: b -> Int -> forall a. a -> a
g x = f

  2. Eta expand g:

    g :: b -> Int -> a -> a
g x y = f y

Contravariance/covariance of function arrows

Given these definitions:

f :: (Bool -> Bool) -> Char
g :: ((forall a. a -> a) -> Char) -> Int

Previous versions of GHC would typecheck the following:

h :: Int
h = g f

This is because GHC's subtyping rules supported contravariance in function arrows, which is something that simplified subsumption removes. As a result, h will not typecheck on GHC 9.0:

error:
    • Couldn't match type: Bool -> Bool
                     with: forall a. a -> a
      Expected: (forall a. a -> a) -> Char
        Actual: (Bool -> Bool) -> Char
    • In the first argument of ‘g’, namely ‘f’
      In the expression: g f
      In an equation for ‘h’: h = g f
   |
   | h = g f
   |       ^

h can be repaired with manual eta expansion:

h :: Int
h = g (\x -> f x)

Just as simplified subsumption removes contravariance in function arrows, it also removes covariance in function arrows. In concrete terms, h' below will no longer typecheck:

f' :: Char -> forall a. a -> a
g' :: (Char -> Bool -> Bool) -> Int

h' :: Int
h' = g' f'
error:
    • Couldn't match type: forall a. a -> a
                     with: Bool -> Bool
      Expected: Char -> Bool -> Bool
        Actual: Char -> forall a. a -> a
    • In the first argument of ‘g'’, namely ‘f'’
      In the expression: g' f'
      In an equation for ‘h'’: h' = g' f'
   |
   | h' = g' f'
   |         ^^

Once again, h' can be repaired with manual eta expansion:

h' :: Int
h' = g' (\x -> f' x)

Parsing of {-# SCC ... #-} pragmas less permissive

GHC 9.0 implements Proposal 176. Prior to the change, adding an SCC pragma to the code could change its meaning:

ghci> 1 / 2 / 2
0.25
ghci> 1 / {-# SCC ann #-} 2 / 2
1.0

The problem was that (1 / 2) / 2 turned into 1 / (2 / 2). This was fixed by disallowing SCC pragmas in problematic positions, at the cost of disallowing some code that previously was accepted, for example:

    (res, ts) <- withRaw $
         {-# SCC attrParser #-} (AddAttributes <$> attrParser)
         <|>
         {-# SCC pInline #-} (Parsed <$> pInline ilParsers)

This now fails with an error:

src/Commonmark/Inlines.hs:333:10: error:
    A pragma is not allowed in this position: {-# SCC attrParser #-}
    |
333 |          {-# SCC attrParser #-} (AddAttributes <$> attrParser)
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The fix is to parenthesize the entirety of the SCC-d subexpression:

    (res, ts) <- withRaw $
         ({-# SCC attrParser #-} AddAttributes <$> attrParser)
         <|>
         ({-# SCC pInline #-} Parsed <$> pInline ilParsers)

Whitespace-sensitive !, ~, @, and $

GHC 9.0 implements Proposal 229, which means that the !, ~, and @ characters are more sensitive to preceding and trailing whitespace than they were before. As a result, some things which used to parse one way will now parse differently (or throw a parse error). Here are some particular scenarios that you may encounter:

  1. f ~ x = x
    • Before: function named f with a lazy (irrefutable) pattern on its argument x
    • After: After: infix function named (~)

    To restore the old behavior, remove the trailing whitespace after ~, like so:

    f ~x = x
  2. f @ x = y
    • Before: value binding that binds both f and x to y using an as-pattern
    • After: infix function named (@)

    To restore the old behavior, remove the leading and trailing whitespace around @, like so:

    f@x = x
  3. f ! x = x
    • Before: function named f with a bang pattern on its argument x
    • After: infix function named (!)

    To restore the old behavior, remove the trailing whitespace after !, like so:

    f !x = x
  4. f = g @ True
    • Before: visible type application
    • After: application of the infix function (@) to g and True

    To restore the old behavior, remove the trailing whitespace after @, like so:

    f = g @True
  5. f = ($x)
    • Before: operator section that applies the infix function ($) to the argument x
    • After: Template Haskell splice that splices in x :: Q Exp

    To restore the old behavior, add a space between $ and x, like so:

    f = ($ x)
  6. f = (!x)

    • Before: operator section that applies the infix function (!) to the argument x

    • After: parse error:

      error:
    Bang pattern in expression context: !x
    Did you mean to add a space after the '!'?

    As the parse error suggests, the old behavior can be restored by instead writing:

    f = (! x)
  7. data T = MkT ! Int

    • Before: data constructor MkT with a strict Int field

    • After: parse error:

      error: Not a data constructor: ‘!’

    To restore the old behavior, remove the trailing whitespace after !, like so:

    data T = MkT !Int

The order of TH splices is more important

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 9.0:

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 9.0 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

Overloaded Quotation Brackets

GHC 9.0 implements Proposal 246, which means that the type of expression quotation brackets is now generalised from Q Exp to Quote m => m Exp. All other forms of quotation are similarly generalised. There are two main breaking changes as a result:

  1. Top-level unannotated quotations now fail to typecheck due to the monomorphism restriction:

    x = [| 5 ||]

    Fix: Provide a type signature for x or enable NoMonomorphismRestriction.

  2. Methods of the Lift typeclass are restricted from Q to only using methods from Quote. The definition of Lift is now:

    class Lift (t :: TYPE r) where
  lift :: Quote m => t -> m Exp  
  liftTyped :: Quote m => t -> m (TExp t)

    If you have manually defined instances for Lift then it might be necessary to rewrite some type signatures in terms of the more restricted Quote interface. In our testing so far we've not found any Lift instances relying on any special methods of Q.

    Another solution is to use the DeriveLift extension rather than manually defining the instance.

You may consider using the th-compat library if you wish to write backwards-compatible code that uses the Quote type class.

Typed TH quotes and splices have different types

GHC 9.0 implements Proposal 195, which means that typed Template Haskell now uses a Code newtype:

newtype Code m a = Code { examineCode :: m (TExp a) }

In particular, Code is now used in the following places:

  • In a typed TH quote, such as [|| ... ||], if the ... expression has type a, then the quotation has type Quote m => Code m a. (Previously, it would have had type Q (TExp a).)
  • In a typed TH splice, such as $$(...), the ... expression must have type Code Q a for some a. (Previously, it must have had type Q (TExp a).)

You may consider using the th-compat library if you wish to write backwards-compatible typed TH code involving Code.

Type variable order in top-level field selectors

Previous versions of GHC did not specify the order or specificity of type variables in the types of top-level field selectors. GHC 9.0 does specify this, which can impact users of TypeApplications. For example, given the following definitions:

{-# LANGUAGE PolyKinds #-}

newtype P a = MkP { unP :: Proxy a }

newtype N :: Type -> Type -> Type where
  MkN :: forall b a. { unN :: Either a b } -> N a b

Previous versions of GHC would give the following types to unP and unN:

unP :: forall k (a :: k). P a -> Proxy a
unN :: forall a b. N a b -> Either a b

GHC will now give them the following types instead: ::

unP :: forall {k} (a :: k). P a -> Proxy a
unN :: forall b a. N a b -> Either a b

More validity checking in quantified constraints

GHC now performs more validity checks on quantified constraints, meaning that some code will require enabling language extensions that were not previously required. As one example, this code will compile on previous versions of GHC:

{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE TypeFamilies #-}

data family F a

f :: (forall a. Show (F a)) => Int
f = 42

However, it will be rejected with GHC 9.0:

error:
    • Non type-variable argument in the constraint: Show (F a)
      (Use FlexibleContexts to permit this)
    • In the quantified constraint ‘forall a. Show (F a)’
      In the type signature: f :: (forall a. Show (F a)) => Int
  |
7 | f :: (forall a. Show (F a)) => Int
  |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Eager instantiation

GHC now consistently does eager instantiation during type inference. As a consequence, visible type application (VTA) now only works when the head of the application is:

  • A variable
  • An expression with a type signature

For example (let x = blah in id) @Bool True no longer typechecks. You should write let x = blah in id @Bool True instead.

GHC is pickier about nested foralls and contexts in GADT constructors

GHC has a rule that GADT constructors cannot contain nested foralls or contexts in GADT constructors. This was always true in previous released, but GHC 9.0 enforces this rule more strictly. In particular, nested foralls or contexts that occur underneath parentheses are now rejected. This means the following examples will no longer compile on GHC 9.0:

data S a where
  MkS :: (forall a. S a)

data U a where
  MkU :: (Show a => U a)

GHC is pickier about nested foralls and contexts in instance and deriving declarations

Much like GHC does not permit nested foralls or contexts in GADT constructors, it also does not permit them in the types at the tops of instance declarations. GHC also enforces this more strictly in 9.0, so the following examples will no longer compile:

instance (forall a. C a) where ...
instance (Show a => C a) where ...

A similar no-nested-foralls rule applies to types involved in deriving clauses and via types (for instances derived with DerivingVia). The following examples will also be rejected with GHC 9.0:

data T = MkT deriving (C1, (forall x. C2 x))
deriving via (forall x. V x) instance C (S x)

Improved Pattern-Match Coverage checker

The coverage checker will now detect more redundant cases, in particular wrt. long distance information. If for some reason (like bitrot prevention of a debug-only case branch) a redundant or inaccessible right-hand side is not to be flagged, a guard like | GHC.Magic.lazy False should prevent the checker from flagging it as such.

I/O manager (WinIO) related changes

If internal GHC I/O primitives were used you may need to manually add support for WINIO. GHC now emits new pre-processor macros __IO_MANAGER_WINIO__ which can be used to determine whether you are compiling with a compiler that is winio aware.

The compiler also exposes a helper function (<!>) which can be used to select between the WINIO and Posix implementation of a function. An example usage:

#if defined(__IO_MANAGER_WINIO__)
import GHC.IO.Handle.Windows (handleToHANDLE)
import GHC.IO.SubSystem ((<!>))
#endif

to import the required changes. These can be used as

withHandleToHANDLE :: Handle -> (HANDLE -> IO a) -> IO a
withHandleToHANDLE haskell_handle action =
#if defined(__IO_MANAGER_WINIO__)
withHandleToHANDLE = withHandleToHANDLEPosix <!> withHandleToHANDLENative
#else
withHandleToHANDLE = withHandleToHANDLEPosix
#endif

The Win32 package exposes helpers that can be used to aid in supporting WINIO porting.

Library changes

base-4.15.*

unsafeCoerce#

The unsafeCoerce# function has been moved from GHC.Prim to Unsafe.Coerce. As a result, attempting to import unsafeCoerce# from GHC.Prim (or GHC.Base, which previously re-exported unsafeCoerce#) will result in an error with GHC 9.0. A backwards-compatible way to fix the error is to import unsafeCoerce# from GHC.Exts instead.

withForeignPtr

Foreign.ForeignPtr.withForeignPtr is now no longer able to unbox its result. That is, given a program like:

readWord8 :: ForeignPtr Word8 -> IO ...
readWord8 fptr = do
    W8# n <- withForeignPtr fptr $ \p -> peek p
    ...

GHC will now allocate, and then scrutinise, and W8# constructor where in previous versions it did not. This change is due to withForeignPtr now using the new keepAlive# primop (fixing #17760 (closed)), across which the simplifier cannot simplify.

If you measure a significant regression in your program due to the change, the old unboxing behavior can be recovered by using GHC.ForeignPtr.unsafeWithForeignPtr. However, as the name suggests, this operation places an important proof obligation on the call: the action passed must not provably diverge (e.g. loop infinitely or throw an exception). Failure to ensure this can result in unsound program transformations which can result in runtime crashes (see #17760 (closed) and related tickets).

ghc-9.0.*

Module hierarchy

Per #13009 (closed), GHC modules have now been renamed to form a hierarchy under GHC.*. ghc-api-compat package has been created for backward compatibility: it exports new modules with their old names (GHC 8.6). However as some modules have been reorganized internally (split, merged, etc.), there is no longer a one-to-one correspondence between old names and new names.

A good way to find new module names from old ones is to look for the old name in ghc-api-compat's Cabal file. The module list in #13009 (closed) is not kept up to date: it's easier to maintain ghc-api-compat's Cabal file that is mechanically checked against GHC codebase.

hs_fixds

The meaning of the hs_fixds field of HsGroup has changed slightly. It now only contains fixity signatures defined for top-level declarations and class methods defined outside of the class itself. Previously, hs_fixds would also contain fixity signatures for class methods defined inside the class, such as the fixity signature for m in the following example: ::

class C a where
  infixl 4 `m`
  m :: a -> a -> a

If you wish to attain the previous behavior of hs_fixds, use the new hsGroupTopLevelFixitySigs function, which collects all top-level fixity signatures, including those for class methods defined inside classes.

ghc-prim-0.7.*

The Unit data type from GHC.Tuple has been renamed to Solo, per #14673/#18099 (closed).

A new primop, keepAlive#, has been introduced to subsume touch#, which cannot in general be safely transformed by the simplifier. Users of touch# are strongly encouraged to refactor their programs to use keepAlive# where possible. In the case that the program cannot use keepAlive# (e.g. due to values whose lifetimes don't respect lexical scoping), you are strongly encouraged to be in touch with the GHC developers to discuss alternatives.

integer-gmp-1.1 / integer-simple / ghc-bignum-1.0

ghc-bignum package replaces both integer-gmp and integer-simple. The specific backend to use still has to be selected at GHC build time (via ghc-bignum's Cabal flags).

If you were using integer-simple, consider using a GHC distribution built with ghc-bignum's native backend instead.

An integer-gmp-1.1 package is provided for backward compatibility. It is based on ghc-bignum and available whatever backend is used. It allows you to continue to use previous Integer's constructors (S#, Jn#, Jp#) and functions which have been renamed in gch-bignum.

GHC.Integer module is no longer in integer-* packages but directly in base, just like GHC.Natural.

Some GMP specific functions (prime test, secure powmod, etc.) are not implemented in ghc-bignum. All ghc-bignum backends must support the same set of operations with the same deterministic results. We couldn't make the native backend support them (for different reasons, see #18427 (closed)). If you need those functions, you should use another package providing them such as hgmp.

shiftL and shiftR for Natural and Integer now behave similarly to Word and Int when the shift amount is negative: they throw an exception (see #18499 (closed)).

template-haskell-2.17.*

GHC now exports explicit specificity in type variable binders, which means that one can now define type variables that are not eligible for visible type application (also known as inferred type variables). Example:

id1 :: forall a. a -> a -- Here, the `a` is specified
id1 x = x

ex1 = id1 @Int 42 -- Typechecks. The `a` in `forall a`
                  -- is eligible for visible type application.

id2 :: forall {a}. a -> a -- Here, the `a` is inferred
id2 x = x

ex1 = id2 @Int 42 -- Does not typecheck. The `a` in `forall {a}`
                  -- is not eligible for visible type application.

As a result, the TyVarBndr data type in template-haskell is now parameterized by a flag type parameter:

data TyVarBndr flag = PlainTV  Name flag      -- ^ @a@
                    | KindedTV Name flag Kind -- ^ @(a :: k)@

There are two primary ways of instantiating flag:

  • With Specificity:

    data Specificity
  = SpecifiedSpec -- ^ @a@. Eligible for visible type application.
  | InferredSpec  -- ^ @{a}@. Not eligible for visible type application.

    This corresponds to type variable binders that can be marked as specified or inferred, such as in invisible foralls:

    data Type = ForallT [TyVarBndr Specificity] Cxt Type
          | ...

    Note that template-haskell defines the TyVarBndrSpec type synonym as a convenient alias for TyVarBndr Specificity.

  • With (). This corresponds to type variable binders where the notion of specified versus inferred is not meaningful. For example, this is used in type synonyms:

    data TySynEqn = TySynEqn (Maybe [TyVarBndr ()]) Type Type

    Note that template-haskell defines the TyVarBndrUnit type synonym as a convenient alias for TyVarBndr (). Also note that the plainTV and kindedTV functions from Language.Haskell.TH.Lib now return TyVarBndr ().

If you wish to write backwards-compatible code involving TyVarBndrs, you may consider using the Language.Haskell.TH.Datatype.TyVarBndr module from the th-abstraction library.