Changes between Version 5 and Version 6 of TypeFunctionsRenaming


Ignore:
Timestamp:
Sep 12, 2006 6:49:32 PM (9 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TypeFunctionsRenaming

    v5 v6  
    2323Family 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`. 
    2424 
    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. 
     25Despite 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 (see bwlow). 
    2626 
    2727=== Renaming of type instances === 
     
    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. 
    3030 
     31=== Name parents & importing and exporting === 
    3132 
    32 === Name parents & importing and exporting === 
     33GHC, 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.