diff options
author | Ryan Scott <ryan.gl.scott@gmail.com> | 2019-05-12 19:16:37 -0400 |
---|---|---|
committer | Marge Bot <ben+marge-bot@smart-cactus.org> | 2019-05-22 16:56:01 -0400 |
commit | 6efe04dee3f4c584e0cd043b8424718f0791d1be (patch) | |
tree | 8a69d7500190af046add0b4ae43e3e46b0f330a5 /includes | |
parent | 2c15b85eb2541a64df0cdf3705fb9aa068634004 (diff) | |
download | haskell-6efe04dee3f4c584e0cd043b8424718f0791d1be.tar.gz |
Use HsTyPats in associated type family defaults
Associated type family default declarations behave strangely in a
couple of ways:
1. If one tries to bind the type variables with an explicit `forall`,
the `forall`'d part will simply be ignored. (#16110)
2. One cannot use visible kind application syntax on the left-hand
sides of associated default equations, unlike every other form
of type family equation. (#16356)
Both of these issues have a common solution. Instead of using
`LHsQTyVars` to represent the left-hand side arguments of an
associated default equation, we instead use `HsTyPats`, which is what
other forms of type family equations use. In particular, here are
some highlights of this patch:
* `FamEqn` is no longer parameterized by a `pats` type variable, as
the `feqn_pats` field is now always `HsTyPats`.
* The new design for `FamEqn` in chronicled in
`Note [Type family instance declarations in HsSyn]`.
* `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This
means that many of `TyFamDefltEqn`'s code paths can now reuse the
code paths for `TyFamInstEqn`, resulting in substantial
simplifications to various parts of the code dealing with
associated type family defaults.
Fixes #16110 and #16356.
Diffstat (limited to 'includes')
0 files changed, 0 insertions, 0 deletions