Check that the restrictions on equality constraints in instance and class contexts are enforced. We should have tests for that in the testsuite. Document the exact restrictions on the Haskell wiki tutorial page.

TestSimple8:

Fix tcLookupFamInst to gracefully handle this case. (This requires some care to not violate assumptions made by other clients of this function, as it is also used for data families, but I see no fundamental problem.)

Issue a warning if there are two identical instances (as per Roman's suggestion).

To fix superclass equalities (specifically getting the coercion evidence), we could introduce a kind of typelet just for evidence. In fact, re-use HsBind.VarBind and make its right-hand side a specially data structure describing evidence construction, instead of being a general HsExpr. That evidence construction generation can have a case for extracting superclass constraints. The desugarer than has to generate the case expression bringing the equality in scope from that.

GADT:
None.

Misc:

Test Simple17 (corelint error as a dict binding, used to specialise a call to a local function, floats out too far)

Step 1: Replace the existing improvement machinery for FDs by code that generates explicit equalities from the two FD rules. Then, all improvement is by normalisation of equalities, which hopefully allows us to simplify TcSimplify.reduceContext.

Why does the call to reduceList (in reduceContext) extend the LIE? What are the produced extra_eqs? (Put an assert there and run the testsuite to see whether extra_eqs is non-empty in any of the tests.)

Error message of tcfail167 should include "Inaccessible case alternative: Can't match types Char' and Float'" again

Handling of cases expression scrutinising GADTs:

See also test GADT7

Remove the dodgy rigidity test that is in tcConPat right now.

implement proposal where we infer a rigidity flag for case scutinees and pass that down when type checking the patterns,

We infer the rigidity flag for the case scrutinee by generalising its type and checking whether that has an foralls at the top. It's rigid if it has no foralls.

if a pattern has a GADT constructor (ie, any constraints in the data constructor signature), the scutinee must be rigid,

we need to know of types whether they are rigid (not only whether they contain unification variables, but by a flag in the environment that indicates whether the computation of that type involved non-rigid type variables)

Re tcfail167, SPJ proposes that could generate a better error message, at least most of the time. If the "expected type" of a pattern is 's', and we meet a constructor with result type (T t1 ..tn), then one could imagine a 2-step process:

check that 's' is (or can be made to be) of form (T ....)

check that the ... can be unified with t1..tn
If (1) succeeds but (2) fails, the alternative is in accessible. Of course, (2) might fail "later" by generating a constraint that later can't be satisfied, and we won't report that well, but we'd get a good message in the common fails-fast case. We could even improve the message from (1) to say: "Constructor C is from data type T, but a pattern of type s is expected.

Comments:

When we raise a mismatch error in TcSimplify for unresolvable equalities, we effectively tidy the two non-matching types twice. Add a comment to highlight this and say way it is ok (i.e., they are never grouped together with groupErrs or similar).

RankN: When can foralls appear in equalities? What constraints does that place on GADTs? Also, the code in TcTyFuns doesn't really deal with rank-n types properly, esp decompRule. Also test Simple14 & GADT10.

It seems a bit complicated to come up with the most general type. The relevant code is in TcExpr.tcExpr in STEP 4 of the RecordUpd case.

Parsing and Renaming

Todo (low-level): None.

Todo (high-level):

Defaults for associated type synonyms. (Having both a kind signature and vanilla synonym is problematic as in RnNames.getLocalDeclBinders its hard to see that not both of them are defining declarations, which leads to a multiple declarations error. Defaults are quite different from vanilla synonyms anyway, as they usually have tyvars on their rhs that do not occur on the lhs.)

Done:

Parsing and renaming of kind signatures (toplevel and in classes).

Parsing and renaming of indexed type declarations (toplevel and in classes).

Using new syntax with family and instance on top level.

Added -findexed-types switch.

Allowing type tag in export lists to list associated types in the sub-binder list of an import/export item for a class.

Import/export lists: ATs can be listed as subnames of classes and the data constructors of instances of a data family are subnames of that family.

Parsing and renaming of equational constraints in contexts.

Type Checking

If an associated synonym has a default definition, use that in the instances. In contrast to methods, this cannot be overridden by a specialised definition. (Confluence requires that any specialised version is extensionally the same as the default.)

Todo (high-level):

Type checking in the presence of associated synonym defaults. (Default AT synonyms are only allowed for ATs defined in the same class.)

Type check functional dependencies as type functions.

Done:

Kind and type checking of kind signatures.

Kind and type checking of instance declarations of indexed types, including the generation of representation tycons.

Wrapper generation and type checking of pattern matching for indexed data and newtypes.