Changes between Version 7 and Version 8 of TypeFunctionsRenaming
- Dec 28, 2006 7:36:17 PM (8 years ago)
v7 v8 29 29 There 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. 30 30 31 === Name parents & importing and exporting === 31 == Renaming of equational constraints == 32 33 Renaming (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. 34 35 == Name parents & importing and exporting == 32 36 33 37 GHC, 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.