Changes between Version 51 and Version 52 of TypeFunctionsTypeChecking


Ignore:
Timestamp:
Apr 25, 2007 8:34:12 AM (7 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 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. 
    103103 
    104 === Representation of equality axioms === 
     104=== Representation of type synonym instances === 
     105 
     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 
     107{{{ 
     108type instance T [a] Int = Maybe a 
     109}}} 
     110we get 
     111{{{ 
     112type R a = Maybe a 
     113coe co a :: (T [a] Int) ~ (R a) 
     114}}} 
     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. 
    105116 
    106117----