Changes between Version 5 and Version 6 of TypeFunctionsRenaming
- Sep 12, 2006 6:49:32 PM (8 years ago)
v5 v6 23 23 Family names in the heads of type instances are usage occurences, not binders. However, we cannot just use `RnNames.lookupGlobalOccRn` as we are only now determining the binders to construct the global `RdrName` environment. On the other hand, we cannot use `RnNames.newTopSrcBinder` either, although it produces the same name when called multiple times. It does not handle the case, where we define an instance for an imported family. Hence, we introduced a new function `RnEnv.lookupFamInstDeclBndr` that first attempts a lookup, similar to `RnEnv.lookupGlobalOccRn`, but if that fails, instead of raising an error, calls `newTopSrcBinder`. If after all, there is no family declaration in scope, this will be picked up and properly reported during renaming by `RnSource.rnTyClDecl`. 24 24 25 Despite the effort we go to, to get the right `Name` for the family `RdrName`, `getLocalDeclBinders` does not return that name as part of the binders declared by the current binding group - otherwise, we would get a duplicate declaration error. However, we use the `Name` to specify the correct name parent for the data constructors of the instance . 25 Despite the effort we go to, to get the right `Name` for the family `RdrName`, `getLocalDeclBinders` does not return that name as part of the binders declared by the current binding group - otherwise, we would get a duplicate declaration error. However, we use the `Name` to specify the correct name parent for the data constructors of the instance. 26 26 27 27 === Renaming of type instances === … … 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 31 32 32 === Name parents & importing and exporting === 33 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 (i.e., invoking `Name.nameParent_maybe`. 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.newTopSrcBinder` to achieve this when renaming source. We also need an extra measure, even if of much smaller scale, when sucking declarations from interface files in `LoadIface.loadDecl`. Here we make the family the name parent for all implicit things of the declaration.