Entailment of Type Equalities

Our aim is to derive the entailment judgement

g1, .., gn |- w1, .., wm

i.e., whether we can derive the wanted equalities w1 to wm from the given equalities g1, .., gn under a given set of toplevel equality schemas (i.e., equalities involving universally quantified variables). We permit unification variables in the wanted equalities, and a derivation may include the instantiation of these variables; i.e., may compute a unifier. However, that unifer must be most general.

The derivation algorithm is complicated by the pragmatic requirement that, even if there is no derivation for the judgement, we would like to compute a unifier. This unifier should be as specific as possible under some not yet specified (strongest) weakening of the judgement so that it is derivable. (Whatever that means...)

The following is based on ideas for the new, post-ICFP'08 solving algorithm described in CVS papers/type-synonym/new-single.tex. A revised version of new-single.tex that integrates the core ideas from this wiki page is in papers/type-synonym/normalised_equations_algorithm.tex. Most of the code is in the module TcTyFuns.

Terminology

Wanted equality

An equality constraint that we need to derive during type checking. Failure to derive it leads to rejection of the checked program.

Local equality, given equality

An equality constraint that -in a certain scope- may be used to derive wanted equalities.

Flexible type variable, unification variable, HM variable

Type variables that may be globally instantiated by unification. We use Greek letters alpha, beta,... as names for these variables.

Rigid type variable, skolem type variable

Type variable that cannot be globally instantiated, but it may be locally refined by a local equality constraint. We use Roman letters a, b,... as names for these variables.

In positions where we can have both flexible and rigid variables, we use x, y, z.

Overall algorithm

The overall structure is as in new-single.tex, namely

normalise all constraints (both locals and wanteds),

solve the wanteds, and

finalise.

However, the three phases differ in important ways. In particular, normalisation includes decompositions & the occurs check, and we don't instantiate any flexible type variables before we finalise (i.e., solving is purely local).

Normal equalities

Central to the algorithm are normal equalities, which can be regarded as a set of rewrite rules. Normal equalities are carefully oriented and contain synonym families only as the head symbols of left-hand sides. They assume one of the following two major forms:

Family equality:co :: F t1..tn ~ t or

Variable equality:co :: x ~ t, where we again distinguish two forms:

Variable-term equality:co :: x ~ t, where t is not a variable, or

Variable-variable equality:co :: x ~ y, where x > y.

where

the types t, t1, ..., tn may not contain any occurrences of synonym families,

the left-hand side of an equality may not occur in the right-hand side, and

the relation x > y is a total order on type variables, where alpha > a whenever alpha is a flexible and a a rigid type variable (otherwise, the total order may be aribitrary).

The second bullet of the where clause is trivially true for equalities of Form (1); it also implies that the left- and right-hand sides are different.

Observations

Normal equalities are similar to equalities meeting the Orientation Invariant and Flattening Invariant of new-single, but they are not the same.

Normal equalities are never self-recursive. They can be mutually recursive. A mutually recursive group will exclusively contain variable equalities.

Coercions

Coercions co are either wanteds (represented by a flexible type variable) or givens aka locals (represented by a type term of kind CO). In GHC, they are represented by TcRnTypes.EqInstCo, which is defined as

type EqInstCo = Either
TcTyVar -- case for wanteds (variable to be filled with a witness)
Coercion -- case for locals

Normalisation

The following function norm turns an arbitrary equality into a set of normal equalities. As in new-single, the evidence equations are differently interpreted depending on whether we handle a wanted or local equality.

The substitutions RECORDed during flatten need to be (unconditionally) applied during finalisation (i.e., the 3rd phase).

Notes:

Perform Rule Triv as part of normalisation.

Whenever an equality of Form (2) or (3) would be recursive, the program can be rejected on the basis of a failed occurs check. (Immediate rejection is always justified, as right-hand sides do not contain synonym familles; hence, any recursive occurrences of a left-hand side imply that the equality is unsatisfiable.)

We flatten locals and wanteds in the same manner, using fresh flexible type variables. (We have flexibles in locals anyway and don't use (Unify) during normalisation - this is different to new-single.)

TODO We may want to drop the alpha > x for all x already used side condition on fresh alphas again. Instead, we should probably consider all local flexible variable equalities during finalisation, too. At least, those involving flexible variables introduced by flattening.

Propagation (aka Solving)

Propagation is based on four rules that transform family and variable equalities. The first rule transforms a family equality using a toplevel equality schema. The other three use one equality to transform another. In the presentation, the transforming equality is always first and the transformed is second, separate by an ampersand (&).

Below the rules are two scheme for applying the rules. The first one naively iterates until the system doesn't change anymore. The second scheme optimises the iteration somewhat.

where co1 is local, or both co1 and co2 are wanted and at least one of the equalities contains a flexible variable.

NB: Afterwards, we need to normalise co2'. Then, the SubstVarVar or SubstVarFam rules may apply to the results of normalisation. Moreover, co1 may have a SubstFam or a SubstVarFam match with rules other than the results of normalising co2'.

where co1 is local, or both co1 and co2 are wanted and at least one of the equalities contains a flexible variable.

NB: Afterwards, we need to normalise co2'. Then, the SubstVarVar or SubstVarFam rules may apply to the results of normalisation, but not with co1, as s and t cannot contain x - cf. the definition of normal equalities. However, co1 may have another SubstVarVar or SubstVarFam match with rules other than the results of normalising co2'.

Observations

Only SubstVarFam when replacing a variable in a family equality can lead to recursion with (Top).

A significant difference to new-single is that solving is a purely local operation. We never instantiate any flexible variables.

We cannot discard any variable equalities after substitution since we do not substitute into right-hand sides anymore. Moreover, in the concrete implementation, variables may also be re-introduced due to simplification of type classes (which currently doesn't happen in the same iteration).

Finalisation

If only flexible type equalities remain as wanted equalities, the locals entail the wanteds. We can now instantiate type variables in flexible type equalities where possible to propagate constraints into the environment. In GHC, we may wrap any remaining equalities (of any form) into an implication constraint to be propagated outwards (where it may be solved under an extended set of local equalities.)

Notes:

(Unify) is an asymmetric rule, and hence, only fires for equalities of the form x ~ c, where c is free of synonym families. Moreover, it only applies to wanted equalities. (Rationale: Local equality constraints don't justify global instantiation of flexible type variables - just as in new-single.)

TODO Still need to adapt example to new rule set!

TODO Now that we delay instantiation until after solving, do we still need to prioritise flexible variables equalities over rigid ones? (Probably not.) In any case, we need to handle variable-variable equalities (at least of flexibles) specially during finalisation. Even if they locals, they need to be taken into account during finalisation. (Otherwise, we may miss some instantiations of flexibles that occur in the environment.)

Examples

Substituting wanted family equalities with SubstFam is crucial if the right-hand side contains a flexible type variable

TODO If we use flexible variables for the flattening of the wanteds, too, the equality corresponding to x ~ a above will be oriented the other way around. That can be a problem because of the asymmetry of the SubstVar and SubstFun rules (i.e., wanted equalities are not substituted into locals).

Termination

SkolemOccurs

The Note [skolemOccurs loop] in the old code explains that equalities of the form x ~ t (where x is a flexible type variable) may not be used as rewrite rules, but only be solved by applying Rule Unify. As Unify carefully avoids cycles, this prevents the use of equalities introduced by the Rule SkolemOccurs as rewrite rules. For this to work, SkolemOccurs also had to apply to equalities of the form a ~ t[[a]]. This was a somewhat intricate set up that we seek to simplify here. Whether equalities of the form x ~ t are used as rewrite rules or solved by Unify doesn't matter anymore. Instead, we disallow recursive equalities after normalisation completely (both locals and wanteds). This is possible as right-hand sides are free of synonym families.

To look at this in more detail, let's consider the following notorious example:

E_t: forall x. F [x] ~ [F x]
[F v] ~ v ||- [F v] ~ v

New-single: The following derivation shows how the algorithm in new-single fails to terminate for this example.

New-single using flexible tyvars to flatten locals, but w/o Rule (Local) for flexible type variables: With (SkolemOccurs) it is crucial to avoid using Rule (Local) with flexible type variables. We can achieve a similar effect with new-single if we (a) use flexible type variables to flatten local equalities and (b) at the same time do not use Rule (Local) for variable equalities with flexible type variables. NB: Point (b) was necessary for the ICFP'08 algorithm, too.

A serious disadvantage of this approach is that we do want to use Rule (Local) with flexible type variables as soon as we have rank-n signatures. In fact, the lack of doing so is responsible for a few failing tests in the testsuite in the GHC implementation of (SkolemOccurs).

De-prioritise Rule (Local): Instead of outright forbidding the use of Rule (Local) with flexible type variables, we can simply require that Local is only used if no other rule is applicable. (That has the same effect on satisfiable queries, and in particular, the present example.)