Changes between Version 56 and Version 57 of Records/OverloadedRecordFields/Implementation


Ignore:
Timestamp:
Aug 30, 2013 10:30:28 AM (8 months ago)
Author:
adamgundry
Comment:

data families

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Implementation

    v56 v57  
    5959{{{ 
    6060data AvailInfo      = Avail Name | AvailTC Name [Name] AvailFields 
    61 data AvailFlds name = NonOverloaded [name] | Overloaded [OccName] 
     61data AvailFlds name = NonOverloaded [name] | Overloaded [(OccName, name)] 
    6262type AvailFields    = AvailFlds Name 
    6363}}} 
    6464 
    65 The `AvailTC` constructor represents a type and its pieces that are in scope. Record fields are now stored in a separate list (the third argument). If the fields are not overloaded, we store the selector names, whereas if they are overloaded, we store only the labels. 
    66  
    67 '''AMG''' This isn't quite enough, because we need to know the module of the selectors. (Data families mean this need not be the same as the parent's module.) I'm inclined to use `Overloaded [(OccName, name)]` in the interests of simplicity, and because otherwise we have to go to some trouble to avoid `gresFromAvails` outside the monad. 
    68  
    69 The `IEThingWith name [name] [OccName]` constructor of `IE`, which represents a thing that can be imported or exported, stores only the `OccName`s. 
     65The `AvailTC` constructor represents a type and its pieces that are in scope. Record fields are now stored separately in the third argument. If the fields are not overloaded, we store only the selector names, whereas if they are overloaded, we store the labels as well. The `IEThingWith name [name] (AvailFlds name)` constructor of `IE` represents a thing that can be imported or exported, and also has a separate argument for fields. 
     66 
     67Note that an `OccName` and parent is not enough to uniquely identify a selector, because of data families: if we have 
     68 
     69{{{ 
     70module M ( F (..) ) where 
     71  data family F a 
     72  data instance F Int { foo :: Int } 
     73 
     74module N ( F (..) ) where 
     75  import M ( F(..) ) 
     76  data instance F Char { foo :: Char } 
     77}}} 
     78 
     79then `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. 
    7080 
    7181 
     
    217227}}} 
    218228 
    219 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 to associate it with its data constructor (`extendRecordFieldEnv` in `RnSource`). 
    220  
    221 For the moment, I've simply disallowed duplicate fields for a single data family in a single module. It's fine to duplicate fields between different data families or across different modules, however. 
     229However, 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.   
     230 
     231For 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. 
    222232 
    223233 
     
    240250* Add `HsVarOut RdrName id` instead of `HsSingleRecFld` (or perhaps rename `HsVar` to `HsVarIn`); also useful to recall how the user referred to something. 
    241251 
     252* What to do about data families with overloaded fields? 
    242253* Support virtual fields or forbid them? 
    243254* Sort out reporting of unused imports.