[source]

compiler/types/Class.hs

Note [Associated type defaults]

[note link]

The following is an example of associated type defaults:
class C a where
data D a r
type F x a b :: *
type F p q r = (p,q)->r    -- Default

Note that

  • The TyCons for the associated types share type variables with the class, so that we can tell which argument positions should be instantiated in an instance decl. (The first for ‘D’, the second for ‘F’.)

  • We can have default definitions only for type families, not data families

  • In the default decl, the “patterns” should all be type variables, but (in the source language) they don’t need to be the same as in the ‘type’ decl signature or the class. It’s more like a free-standing ‘type instance’ declaration.

  • HOWEVER, in the internal ClassATItem we rename the RHS to match the tyConTyVars of the family TyCon. So in the example above we’d get a ClassATItem of

    ATI F ((x,a) -> b)

    So the tyConTyVars of the family TyCon bind the free vars of the default Type rhs

The @mkClass@ function fills in the indirect superclasses.

The SrcSpan is for the entire original declaration.

Note [Associated type tyvar names]

[note link]

The TyCon of an associated type should use the same variable names as its parent class. Thus

class C a b where
type F b x a :: *

We make F use the same Name for ‘a’ as C does, and similary ‘b’.

The reason for this is when checking instances it’s easier to match them up, to ensure they match. Eg

instance C Int [d] where
type F [d] x Int = ….

we should make sure that the first and third args match the instance header.

Having the same variables for class and tycon is also used in checkValidRoles (in TcTyClsDecls) when checking a class’s roles.