... | ... | @@ -12,7 +12,7 @@ This guide summarises the changes you may need to make to your code to migrate f |
|
|
### Implicit kind variable changes
|
|
|
|
|
|
|
|
|
GHC 8.10 implements [proposal 24](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst), which means that GHC is much less likely to implicitly quantify kind variables than it used to be. Here are some examples of code which will no longer work with GHC 8.10:
|
|
|
GHC 8.10 implements [proposal 103](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0103-no-kind-vars.rst), which means that GHC is much less likely to implicitly quantify kind variables than it used to be. Here are some examples of code which will no longer work with GHC 8.10:
|
|
|
|
|
|
* Kind variables are no longer implicitly quantified when an explicit `forall` is used at the beginning of a function's type signature. For instance, the following will no longer work:
|
|
|
|
... | ... | @@ -57,8 +57,8 @@ GHC 8.10 implements [proposal 24](https://github.com/ghc-proposals/ghc-proposals |
|
|
* Kind variables are no longer implicitly quantified in data constructor declarations:
|
|
|
|
|
|
```hs
|
|
|
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
|
|
|
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
|
|
|
```
|
|
|
|
|
|
As the above examples show, code that breaks because of this change can generally be fixed by adding explicit kind signatures to the type variable binders of the data type itself.
|
... | ... | @@ -114,7 +114,7 @@ Foo.hs:11:20: error: |
|
|
| ^^^^
|
|
|
```
|
|
|
|
|
|
To fix this issue, one must give `ST` a complete, user-specified kind signature (consult [the relevant users' guide section](https://downloads.haskell.org/~ghc/8.6.4/docs/html/users_guide/glasgow_exts.html#complete-user-supplied-kind-signatures-and-polymorphic-recursion) for a more detailed description on what this means). In other words, apply the following change:
|
|
|
To fix this issue in a backwards-compatible way, one can give `ST` a complete, user-specified kind signature (consult [the relevant users' guide section](https://downloads.haskell.org/~ghc/8.6.4/docs/html/users_guide/glasgow_exts.html#complete-user-supplied-kind-signatures-and-polymorphic-recursion) for a more detailed description on what this means). In other words, apply the following change:
|
|
|
|
|
|
```diff
|
|
|
-data ST a :: T a -> Type where
|
... | ... | @@ -197,4 +197,19 @@ The new default implementation is in terms of `liftTyped`: |
|
|
This will affect any `Lift` instance that does not explicitly define `lift`. There are two ways to adapt to this change:
|
|
|
|
|
|
1. Derive the `Lift` instance using the `DeriveLift` extension, which has been available since GHC 8.0.
|
|
|
2. Explicitly define `liftTyped`, guarding it with `#if MIN_VERSION_template_haskell(2,16,0) ... #endif` if you want to preserve backwards compatibility with older versions of `template-haskell`. |
|
|
\ No newline at end of file |
|
|
2. Explicitly define `liftTyped`, guarding it with `#if MIN_VERSION_template_haskell(2,16,0) ... #endif` if you want to preserve backwards compatibility with older versions of `template-haskell`.
|
|
|
|
|
|
#### `TupE`/`UnboxedTupE` changes
|
|
|
|
|
|
The types of the `TupE` and `UnboxedTupE` constructors have changed:
|
|
|
|
|
|
```diff
|
|
|
data Exp
|
|
|
= ...
|
|
|
- | TupE [Exp]
|
|
|
- | UnboxedTupE [Exp]
|
|
|
+ | TupE [Maybe Exp]
|
|
|
+ | UnboxedTypE [Maybe Exp]
|
|
|
```
|
|
|
|
|
|
This is because `TupE` and `UnboxedTupE` are now capable of handling tuple sections. For example, `(1,)` is represented with `TupE [Just (LitE (IntegerL 1)), Nothing]` as an `Exp`. |
|
|
\ No newline at end of file |