Changes between Version 51 and Version 52 of TypeFunctionsTypeChecking

Apr 25, 2007 8:34:12 AM (10 years ago)



  • TypeFunctionsTypeChecking

    v51 v52  
    102102NB: It is necessary to refine the `TyCon.isNewTyCon` predicate by introducing `TyCon.isClosedNewTyCon` and using it in all places where the predicate is used to determine whether a newtype can be expanded to its right hand side.  In principle, this is also possible for families, but only in dependence on the concrete type arguments (and newtype instances in scope), so it would be much harder to check.  Hence, for now, newtype families are opaque.
    104 === Representation of equality axioms ===
     104=== Representation of type synonym instances ===
     106The basic structure of the representation of `type instance`s is the same as for data and newtypes.  Every instances is represented by a representation `TyCon.TyCon`, which in the synonym case is of the `SynTyCon` variant.  We extended `SynTyCon` by a new field `synTcParent :: TyConParent` that contains the same sort of parent information as for data types.  In particular, it refers to a coercion that moves between the family instance and the representation tycon.  This coercion is created with `Coercion.mkFamInstCoercion`.  As an example, for
     108type instance T [a] Int = Maybe a
     110we get
     112type R a = Maybe a
     113coe co a :: (T [a] Int) ~ (R a)
     115This may appear overly complicated as we could have created a coercion that has `Maybe a` as its right-hand side, avoiding a representation type `R` entirely.  However, inside GHC, the representation tycon conveniently stores all the information about the type instance (including its coercion), which the coercion by itself could not.  Moreover, we also use it to represent the instance in interface files.