Changes between Version 18 and Version 19 of Records/OverloadedRecordFields/Implementation


Ignore:
Timestamp:
Jul 31, 2013 2:00:22 PM (9 months ago)
Author:
adamgundry
Comment:

worrying about dfunids

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Implementation

    v18 v19  
    2323== The naming of cats == 
    2424 
    25 The `AvailTC Name [Name] [(OccName, Name)]` constructor of `AvailInfo` represents a type and its pieces that are in scope. Record fields are now stored in a separate list (the third argument), along with their selectors (TODO: replace with dfun names). The `IEThingWith name [name] [OccName]` constructor of `IE`, which represents a thing that can be imported or exported, only stores the field labels. '''SLPJ''' Whoa!  Why should we duplicate this info.  My gut feel is that the selector should not appear in the second argument. '''AMG''' Does this sound better now? It's helpful if `gresFromAvail` need not do lookups (it is called by the desugarer). 
     25The `AvailTC Name [Name] [(OccName, Name)]` constructor of `AvailInfo` represents a type and its pieces that are in scope. Record fields are now stored in a separate list (the third argument), along with their selectors. The `IEThingWith name [name] [OccName]` constructor of `IE`, which represents a thing that can be imported or exported, only stores the field labels. '''SLPJ''' Whoa!  Why should we duplicate this info.  My gut feel is that the selector should not appear in the second argument. '''AMG''' Does this sound better now? It's helpful if `gresFromAvail` need not do lookups (it is called by the desugarer). 
    2626 
    2727The `Parent` type has an extra constructor `FldParent Name OccName` that stores the parent `Name` and the field `OccName`. The `GlobalRdrElt` (`GRE`) for a field stores the selector name directly, and uses the `FldParent` constructor to store the field. Thus a field `foo` of type `T` gives rise this entry in the `GlobalRdrEnv`: 
     
    3131}}} 
    3232 
    33 '''SLPJ''' moreover I think we should store the ''dictionary'' `$dfHasTfoo` in the GRE for `foo`, not the selector.  That way we get both getter and setter (via the dictionary) in one go.  '''AMG''' I'm working on this. 
     33'''SLPJ''' moreover I think we should store the ''dictionary'' `$dfHasTfoo` in the GRE for `foo`, not the selector.  That way we get both getter and setter (via the dictionary) in one go.  '''AMG''' Now I'm not sure about this. We can't build the dictionary for higher-rank fields, but they have a perfectly good selector. Moreover, if we want type-changing update there will be two dictionaries (one for the getter and one for the setter). 
    3434 
    3535Note that the `OccName` used when adding a GRE to the environment (`greOccName`) now depends on the parent field: for `FldParent` it is the field label rather than the selector name. 
    3636 
    37 The `dcFields` field of `DataCon` stores a list of 
     37The `dcFields` field of `DataCon` stores a list of `FieldLabel`, defined thus: 
    3838 
    3939{{{ 
    40 type FieldLabel = (OccName, Name) 
     40type FieldLbl a = FieldLabel { 
     41                      flOccName  :: OccName, -- ^ Label of the field 
     42                      flSelector :: a        -- ^ Record selector function 
     43                  } 
     44type FieldLabel = FieldLbl Name 
    4145}}} 
    4246 
    43 where the first component is the field and the second is the selector function (TODO: dfun name). 
     47whereas the `ifConFields` field of `IfaceConDecl` stores a list of `FieldLbl OccName`. 
    4448 
    4549 
     
    8387`Has` instances are generated, provided the extension is enabled, in `tcInstDecls1` (the same time as derived instances (from '''deriving''' clauses) are generated). Every record field `GRE` in scope gives rise to an instance. Such instances are available when typechecking the current module (in `tcg_inst_env`) but not exported to other modules (via `tcg_insts`). At the moment, fresh `DFunId`s are generated for all instances in scope for each module, even though they are exported in interface files. Perhaps this should change. 
    8488 
     89'''AMG''' I wanted to generate each `DFunId` for `Has` once, at the field's definition site, but this causes problems for the fields defined in `base`, as the `Has` class may not be available. I've reverted to generating fresh `DFunId`s locally to each module for which `-XOverloadedRecordFields` is used. Is there a better way to do this? 
     90 
    8591 
    8692== Unused imports == 
     
    122128== To do == 
    123129 
    124 Only projection is implemented, not update, so there is no lens integration. We need to decide on a story here. 
    125  
    126 Rather than generating fresh `DFunId`s for all the fields in scope, only generate them for locally-defined fields, and pass them around so that other modules can use them. 
     130Only projection is implemented, not update, so there is no lens integration yet. We need to decide on a story here. 
    127131 
    128132Implement the syntactic sugar `r { x :: t }`.