Type Functions: Implementation Status

Debugging of type families:

We would need swapInsts for wanted constraints. However, an alternative is to get rid of swapInst altogether and to make substInst a bit smarter (so it also applies wrongly-oriented equalities properly).

boxySplitTyConApp and friends must be able to deal with orig_tys that have outermost type family applications; i.e., they need to try to normalise and possibly have to defer. They also need to defer on skolems. Consequently, they also need to return a coercion. This , in particular, affects the treatment of literal lists, parallel arrays, and tuples inTcExpr.tcExpr is fishy.

To move GADT type checking from refinements to equalities, proceed as follows (as suggested by SPJ):

The remaining problems are partially due to (1) the splitBoxyXXX function issue mentioned above, (2) the occurs check issue mentioned below, (3) the same problem exhibited by GADT9 (with or without this change), (4) some problems getting hold of the right given class constraints, and (5) some random stuff that I haven't looked at more closely.

In TcUnify, make all occurs checks more elaborate. They should only defer if the checked variable occurs as part of an argument to a type family application; in other cases, still fail right away.

TcGadt.tcUnifyTys can now probably be replaced again by the non-side-effecting unifier that was in types/Unify.hs (recover from previous repo states).

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.

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.

To fix Simple8:

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).

CONCEPTUAL issue: At least with skolemOccurs, the policy of not zonking the types embedded in the kinds of coercion type variables does no longer work. This becomes, for example in the test Simple13, apparent. The skolem introduced in skolemOccurs finds its way into variable kinds (which is visible when inspecting them during TcMType.zonk_tc_tyvar).

When Simple13 is compiled with a compiler that was built with -DDEBUG, it prints a warning about not matching types being used during constructing a trans coercion.

In TcTyFuns.genericNormaliseInst, we need to figure out what to do with ImplicInst, Method, and LitInst dictionaries.

The tests tcfail068 and rw used to raise more type errors right away. Now, we see less recovery.

What about filtering the EqInsts in TcSimplify.addSCs. We need them, don't we? But they give rise to Vars, not Ids, and we haven't got selectors.

Current:

Add some trac wiki documentation of how inference with type families works.

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

Todo (low-level):

Allow data family GADT instances.

Deriving Typeable for data families.

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 of type families; routines in TcUnify that still need to be extended:

boxySplitTyConApp: The second argument (BoxyRhoType) can be a synonym family application. Then, we must produce a wanted coercion and return a HsWrapper value that applies that coercion.

boxySplitAppTy: Basically, the same deal as the previous.

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.

tcfail046: VALID. Changed error message, BUT the new error message has one more type synonym unfolding, which should be avoided.

tcfail065: VALID. Cosmetic difference, as tidy names are assigned in different order.

tcfail068: VALID. Reports two errors less (probably due to different recovery points). Yes, I checked that its not that it admits incorrect programs, but just due to different order of checking/pruning of errors.

tcfail071: VALID. Now reports one instead of two errors as deferred unification is checked only after the contexts of mutually recursive groups have been unified. (The latter is what this test case is really about, and it still works fine for that.)

tcfail076: VALID. Same as tcfail065.

tcfail102: VALID.

tcfail103: VALID. Error message is actually better!

tcfail128: VALID. Same as tcfail046.

tcfail145: VALID. Error message got worse.

tcfail153: VALID. Error message is different, but equally correct and accurate. The type mismatch manifests itself at two different subexpressions. Due to a different traversal order, we now report the error at the other subexpression.

tcfail179: VALID. If anything, the error message improved.

while: VALID. Works if definition of succeed gets a type signature Monad m => a -> m a. The error seems to be due to the new GADT rules about annotations, but the error message is a bit strange; ie, need to be improved.