Note [Error on unconstrained meta-variables]
Consider
* type C :: Type -> Type -> Constraint
class (forall a. a b ~ a c) => C b c
* type T = forall a. Proxy a
* data (forall a. a b ~ a c) => T b c
* type instance F Int = Proxy Any
where Any :: forall k. k
In the first three cases we will infer a :: Type -> kappa, but then
we get no further information on kappa. In the last, we will get
Proxy kappa Any
but again will get no further info on kappa.
What do do?
A. We could choose kappa := Type. But this only works when the kind of kappa
is Type (true in this example, but not always).
B. We could default to Any.
C. We could quantify.
D. We could error.
We choose (D), as described in #17567, and implement this choice in
doNotQuantifyTyVars. Discussion of alternatives A-C is below.
NB: this is all rather similar to, but sadly not the same as
Note [Naughty quantification candidates]
To do this, we must take an extra step before doing the final zonk to create
e.g. a TyCon. (There is no problem in the final term-level zonk. See the
section on alternative (B) below.) This extra step is needed only for
constructs that do not quantify their free meta-variables, such as a class
constraint or right-hand side of a type synonym.
Specifically: before the final zonk, every construct must either call
quantifyTyVars or doNotQuantifyTyVars. The latter issues an error
if it is passed any free variables. (Exception: we still default
RuntimeRep and Multiplicity variables.)
Because no meta-variables remain after quantifying or erroring, we perform
the zonk with NoFlexi, which panics upon seeing a meta-variable.
Alternatives A-C, not implemented:
A. As stated above, this works only sometimes. We might have a free
meta-variable of kind Nat, for example.
B. This is what we used to do, but it caused Any to appear in error
messages sometimes. See #17567 for several examples. Defaulting to
Any during the final, whole-program zonk is OK, though, because
we are completely done type-checking at that point. No chance to
leak into an error message.
C. Examine the class declaration at the top of this Note again.
Where should we quantify? We might imagine quantifying and
putting the kind variable in the forall of the quantified constraint.
But what if there are nested foralls? Which one should get the
variable? Other constructs have other problems. (For example,
the right-hand side of a type family instance equation may not
be a poly-type.)
More broadly, the GHC AST defines a set of places where it performs
implicit lexical generalization. For example, in a type
signature
f :: Proxy a -> Bool
the otherwise-unbound a is lexically quantified, giving us
f :: forall a. Proxy a -> Bool
The places that allow lexical quantification are marked in the AST with
HsImplicitBndrs. HsImplicitBndrs offers a binding site for otherwise-unbound
variables.
Later, during type-checking, we discover that a's kind is unconstrained.
We thus quantify *again*, to
f :: forall {k} (a :: k). Proxy @k a -> Bool
It is this second quantification that this Note is really about --
let's call it *inferred quantification*.
So there are two sorts of implicit quantification in types:
1. Lexical quantification: signalled by HsImplicitBndrs, occurs over
variables mentioned by the user but with no explicit binding site,
suppressed by a user-written forall (by the forall-or-nothing rule,
in Note [forall-or-nothing rule] in GHC.Hs.Type).
2. Inferred quantification: no signal in HsSyn, occurs over unconstrained
variables invented by the type-checker, possible only with -XPolyKinds,
unaffected by forall-or-nothing rule
These two quantifications are performed in different compiler phases, and are
essentially unrelated. However, it is convenient
for programmers to remember only one set of implicit quantification
sites. So, we choose to use the same places (those with HsImplicitBndrs)
for lexical quantification as for inferred quantification of unconstrained
meta-variables. Accordingly, there is no quantification in a class
constraint, or the other constructs that call doNotQuantifyTyVars. References 1
- Naughty quantification candidates GHC.Tc.Utils.TcMType
Referenced by 9
- GHC.Tc.TyCl call site ×4
- Unquantified tyvars in a pattern synonym GHC.Tc.TyCl.PatSyn
- Naughty quantification candidates GHC.Tc.Utils.TcMType
- GHC.Tc.Utils.TcMType call site
- Un-unified unification variables GHC.Tc.Zonk.Env
- GHC.Tc.Zonk.Env call site