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


Ignore:
Timestamp:
Aug 1, 2013 3:18:14 PM (9 months ago)
Author:
adamgundry
Comment:

simple update is now supported

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Implementation

    v19 v20  
    1818 
    1919$dfHasTx :: Has T "x"      -- corresponds to the Has instance decl 
    20 $dfHasTx = Has $sel_x_T 
     20$dfHasTx = Has { getField _     = $sel_x_T 
     21               , setField _ s e = s { x = e } } 
     22 
     23axiom TFCo:R:GetResult : GetResult T "x" = Int  -- corresponds to the GetResult type family instance 
    2124}}} 
    2225 
     
    8992'''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? 
    9093 
     94As well as `Has` instances, instances of the type family `GetResult` are generated, and exactly the same question about dfun names applies to their axiom names. 
     95 
    9196 
    9297== Unused imports == 
     
    128133== To do == 
    129134 
    130 Only projection is implemented, not update, so there is no lens integration yet. We need to decide on a story here. 
     135Simple update is implemented, using the design [https://github.com/adamgundry/records-prototype/blob/master/SimpleRecords.hs here]. The next step is to implement type-changing update. 
    131136 
    132137Implement the syntactic sugar `r { x :: t }`. 
     
    134139Test the interaction between fields and qualified names. In particular, a qualified name can be used for unambiguous identification of fields (e.g. in updates) but should probably not be used as an overloaded variable. 
    135140 
    136 Universally quantified fields should result in a warning being emitted and no Has instance generated. What about existentially quantified fields? 
     141Universally quantified fields should result in a warning being emitted and no Has instance generated. What about existentially quantified fields (naughty record selectors)? 
    137142 
    138143How should deprecation work for fields? Not at all?