Changes between Version 13 and Version 14 of Records/DeclaredOverloadedRecordFields


Ignore:
Timestamp:
Feb 21, 2012 11:44:37 PM (2 years ago)
Author:
guest
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields

    v13 v14  
    178178{{{ 
    179179    case r of { 
    180       Cust_Price {unit_Price, ..}    -> Cust_Price {unit_Price = unit_Price * 1.05, .. } 
     180      Cust_Price{ unit_Price, .. }    -> Cust_Price{ unit_Price = unit_Price * 1.05, .. } 
    181181      }                                          -- increases Price by 5% 
    182182}}} 
     
    189189Returns a record with same fields as `myPrice`, except a different `unit_Price`. Note that the update can change the type of a field (if the record declaration is polymorphic). 
    190190 
    191 Note that upon first encountering that expression, we don't know the record types (because `unit_Price` is overloaded). So the types initially inferred are: 
     191Upon first encountering that expression, we don't know the record types (because `unit_Price` is overloaded). So the types initially inferred are: 
    192192{{{ 
    193193    <expr>  :: r { unit_Price :: Int } => r 
     
    196196That is, the update might be changing the record type as well as the field type -- in case that the record type is parametric over the field type. 
    197197 
    198 Behind the scenes, the update syntax with an expression prefix to the `{ ... }` is syntactic sugar for a call to the polymorphic record update method `set`: 
     198Behind the scenes, the update syntax with an expression prefix `e{ ... }` (as opposed to a data constructor `MkT{ .. }`) is syntactic sugar for a call to the polymorphic record update method `set`: 
    199199{{{ 
    200200    set (undefined :: Proxy_unit_Price) (72 :: Int) myPrice 
     
    206206You can update multiple fields at the same time: 
    207207{{{ 
    208     myCustNA { firstName = "Fred", lastName = "Dagg" } 
     208    myCustNA{ firstName = "Fred", lastName = "Dagg" } 
    209209}}} 
    210210    [There's a poor story to tell here in implementation terms: we split into two calls to `set`, one nested inside the other. It's wasteful to build the intermediate record. Worse, the two fields' types might be parametric in the record type or polymorphically related (perhaps one is a method to apply to the other), then we get a type failure on the intermediate record.]