Changes between Version 7 and Version 8 of TypeFunctionsRenaming

Dec 28, 2006 7:36:17 PM (11 years ago)



  • TypeFunctionsRenaming

    v7 v8  
    2929There is little extra that needs to be done for type instances.  The main difference between vanilla synonyms and data/newtype declarations and the indexed variants is that the `tcdTyPats` field is not `Nothing`.  We simply call `rnTyPats` on these fields, which traverses them in the usual way.  Moreover, we need to be careful with the family type constructor in the instance head: it is in an occurence position and needs to be looked up suitably, such that we get a nice "out of scope" error if no appropriate family is in scope.  By the same token, the family names needs to go into the set of free variables.  Finally, `RnSource.rnSrcInstDecl` invokes `RnSource.rnTyClDecl` on all associated types of an instance to rename them.
    31 === Name parents & importing and exporting ===
     31== Renaming of equational constraints ==
     33Renaming (by `RnTypes.rnPred`) and kind checking (by `TcHsType.kc_pred`) is straight forward.  Afterwards, `HsPred` is desugared into `TypeRep.PredType`, where the wellformedness of equational constraints in type contexts is further tested by `TcMType.check_pred_ty`; in particular, we require the type arguments to be rank 0.
     35== Name parents & importing and exporting ==
    3337GHC, in `RnNames`, derives its knowledge of which names may appear in parenthesis after a type or class name in an import or export list by querying the name parent relation, as encoded in `RdrName.gre_par` of `RdrName.GlobalRdrElt`.  Hence, it is crucial that all the data constructors defined in instances of a family get the family name, not the name of the representation tycon, as their name parent.  We go to some effort in `RnNames.getLocalDeclBinders` to achieve this when renaming source.  We also , when sucking declarations from interface files in `LoadIface.loadDecl`, make the family the name parent for all implicit things of the declaration.