Changes between Version 28 and Version 29 of Records/DeclaredOverloadedRecordFields


Ignore:
Timestamp:
Mar 9, 2012 4:17:32 AM (2 years ago)
Author:
AntC
Comment:

clarify rules re Proxy_type decl

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields

    v28 v29  
    4040 
    4141Note that the''' `Has` mechanism''' uses a Proxy as the type 'peg' for a field (this is the wildcard argument to `get` and `set`): 
    42  * The Proxy must be declared once, and is then under regular name control. 
     42 * There must be a Proxy_type declared for each distinct field name. 
     43 * The Proxy must be declared once, and the Proxy is then under regular name control. 
    4344 * The field selector function also must be declared once, defined using the Proxy. 
    4445 
     46    It is an error to declare a record field without there being a Proxy in scope. The desugar for the data decl would create the instance to use the Proxy, but then the instance would fail. 
     47 
     48To generate the correct declarations, there is to be a new `fieldLabel` sugar: 
    4549{{{ 
    4650    fieldLabel customer_id :: r -> Int                                  -- new declaration, desugars to Proxy and func: 
     
    4953    customer_id r = get r (undefined :: Proxy_customer_id) 
    5054 
    51     set (undefined :: Proxy_customer_id) 27 myCust                      -- record update desugarred from above 
    52 }}} 
     55    set (undefined :: Proxy_customer_id) 27 myCust                      -- record update desugarred from above example 
     56}}} 
     57 
     58 * (Admittedly, this could get onerous to declare a `fieldLabel` for every field, even the ones that appear in a single record type. See "Option Three: Mixed In-situ and DeclaredORF: " further down this page for a suggestion of using the DORF mechanism to generate one-off H98-style fields.) 
    5359 
    5460'''Virtual''' or '''pseudo-''' fields are easy to create and use, because field selection is merely function application. Virtual fields look like ordinary fields (but can't be updated, because there is no `Has` instance): 
     
    6470 * Monomorphic fields can be `get` and `set`. 
    6571 * Parametric polymorphic fields can be applied in polymorphic contexts, and can be `set` including changing the type of the record. 
    66  * Higher-ranked polymorphic fields can be applied in polymorphic contexts, but cannot be set.[[BR]]Uses equality constraints on the instance to 'improve' types. 
     72 * Higher-ranked polymorphic fields can be applied in polymorphic contexts, but cannot be set -- for the same reasons as under SORF.[[BR]]The instances use equality constraints to 'improve' types up to polymorphic. 
    6773 * `Has` uses type family functions to manage type-changing update, which adds complexity -- see Implementer's view. 
    6874 * Multiple fields can be updated in a single expression (using familiar H98 syntax), but this desugars to nested updates, which is inefficient.