Changes between Version 13 and Version 14 of Records/DeclaredOverloadedRecordFields


Ignore:
Timestamp:
Feb 21, 2012 11:44:37 PM (4 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.]