Changes between Version 58 and Version 59 of Records/OverloadedRecordFields/Implementation


Ignore:
Timestamp:
Sep 2, 2013 10:13:22 AM (8 months ago)
Author:
adamgundry
Comment:

data families

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Implementation

    v58 v59  
    7777}}} 
    7878 
    79 then `N` exports two different selectors with the `OccName` `"foo"`. It might be enough to use `(OccName, Module)` instead of `(OccName, name)`, but I'm inclined to the latter in the interests of simplicity, and because otherwise we have to go to some trouble to avoid `gresFromAvails` outside the monad. In any case, if we want to allow two data family instances in the same module to use the same field name ([#Datafamilies see below]), the module will not be enough. 
     79then `N` exports two different selectors with the `OccName` `"foo"`. 
    8080 
    8181 
     
    207207}}} 
    208208 
    209 This is perfectly sensible, and should give rise to two *different* record selectors `foo`, and corresponding `Has` instances: 
     209This is perfectly sensible, and gives rise to two *different* record selectors `foo`, and corresponding `Has` instances: 
    210210 
    211211{{{ 
     
    214214}}} 
    215215 
    216 However, what can we call the record selectors? They can't both be `$sel_foo_F`! Ideally we would use the name of the representation tycon, rather than the family tycon, but that isn't introduced until the typechecker (`tcDataFamInstDecl` in `TcInstDcls`), and we need to create the selector in the renamer (`getLocalNonValBinders` in `RnNames`). We can't just pick an arbitrary unique name, because we need to look up the selector and dfuns/axioms later.   
    217  
    218 For the moment, I've simply disallowed duplicate fields for a single data family in a single module. There are still problems if a field is duplicated for a single family across different modules. It's fine to duplicate fields between different data families, however. 
     216Thus we use the name of the representation tycon, rather than the family tycon, when naming the record selectors: we get `$sel_foo_R:FInt` and `$sel_foo_R:FBool`. This requires a bit of care, because lexically (in the `GlobalRdrEnv`) the selectors still have the family tycon are their parent. 
     217 
     218In order to have access to the representation tycon name in the renamer, when the record selector names are generated, it is generated by `getLocalNonValBinders` and stored in a new field `dfid_rep_tycon` of `DataFamInstDecl`.  
    219219 
    220220 
     
    237237* Add `HsVarOut RdrName id` instead of `HsSingleRecFld` (or perhaps rename `HsVar` to `HsVarIn`); also useful to recall how the user referred to something. 
    238238 
    239 * What to do about data families with overloaded fields? 
    240239* Support virtual fields or forbid them? 
    241240* Sort out reporting of unused imports.