... | ... | @@ -17,10 +17,13 @@ a number of projects that broke with confusing type errors due to (often |
|
|
unnecessary) use of `-XImpredicativeTypes`. Users of
|
|
|
`-XImpredicativeTypes` do so at their own risk!
|
|
|
|
|
|
|
|
|
In many cases, this can be fixed by rewriting `a = f . g` to `a x = f (g x)`.
|
|
|
|
|
|
### Requirement for impredicative types
|
|
|
|
|
|
|
|
|
In previous versions of GHC, it was possible to hide an impredicative type behind a type synonym, because GHC did not always expand type synonyms when checking for impredicativity. GHC 8 is stricter in this regard, so code that compiled with `-XRankNTypes` may now require `-XImpredicativeTypes` (bearing in mind its potential brokenness) or may need to be rewritten to avoid impredicativity. See [\#10194](https://gitlab.haskell.org//ghc/ghc/issues/10194), [ this thread](https://mail.haskell.org/pipermail/ghc-devs/2016-February/011367.html) and [ this thread](https://mail.haskell.org/pipermail/ghc-devs/2016-May/012144.html).
|
|
|
In previous versions of GHC, it was possible to hide an impredicative type behind a type synonym, because GHC did not always expand type synonyms when checking for impredicativity. GHC 8 is stricter in this regard, so code that compiled with `-XRankNTypes` may now require `-XImpredicativeTypes` (bearing in mind its potential brokenness) or may need to be rewritten to avoid impredicativity. See [\#10194](https://gitlab.haskell.org//ghc/ghc/issues/10194), [ this thread](https://mail.haskell.org/pipermail/ghc-devs/2016-February/011367.html), [ this thread](https://mail.haskell.org/pipermail/ghc-devs/2016-May/012144.html) and [ this thread](https://mail.haskell.org/pipermail/haskell-cafe/2016-June/124119.html).
|
|
|
|
|
|
### More conservative use of superclass constraints while solving
|
|
|
|
... | ... | |