Changes between Version 10 and Version 11 of Records/DeclaredOverloadedRecordFields


Ignore:
Timestamp:
Feb 21, 2012 2:27:04 AM (3 years ago)
Author:
guest
Comment:

add clarifications, format links -- AntC

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields

    v10 v11  
    77 * ''' DORF -- Application Programmer's view '''     (this page) 
    88 * ''' [wiki:Records/DeclaredOverloadedRecordFields/ImplementorsView DORF -- Implementor's view] ''' 
    9  * ''' [wiki:Records/DeclaredOverloadedRecordFields/COmpareSORF DORF -- Comparison to SORF] ''' 
     9 * ''' [wiki:Records/DeclaredOverloadedRecordFields/COmpareSORF DORF -- Comparison to SORF (and TDNR)] ''' 
    1010 * ''' [wiki:Records/DeclaredOverloadedRecordFields/DotPostfix Dot as Postfix Function Apply] '''   ('''''optional''''' syntactic sugar) 
    1111 * ''' [wiki:Records/DeclaredOverloadedRecordFields/PolyRecordPattern Polymorphic Record Patterns] '''   ('''''speculative''''' future) 
     
    1919 
    2020This proposal is addressing the "narrow issue" of namespacing for record field names. 
    21 http://hackage.haskell.org/trac/ghc/wiki/Records 
     21[wiki:Records] 
    2222 
    2323I'm avoiding giving implementation details here -- see: 
    24     The Implementor's view and Comparison to SORF   (links above) 
     24    The Implementor's view; and Comparison to SORF   (links above) 
    2525 
    2626I'm not saying anything about field selection via pattern matching or record construction using explicit data constructors -- those are to behave as currently (using the approach per ‑XDisambiguateRecordFields and friends). 
     
    125125=== Import/Export and Representation hiding === 
    126126 
    127 [See <No Mono Record Fields>, which is implied by DORF.] 
     127[See [wiki:Records/DeclaredOverloadedRecordFields/NoMonoRecordFields No Mono Record Fields], which is implied by DORF.] 
    128128 
    129129Since there is only a single (overloaded) field selector function created, we either have to export it always, or hide it always (that is, we can't control which record instances get exported). 
     130 
     131But we __can__ control at a record and field level how much of the representation gets revealed. 
    130132 
    131133The field selector function is separately declared vs. the records and their fields, so must be exported separately. For example: 
     
    138140Here only the field selector function `x` is exported. The representation is abstract, the client can't construct or dismantle a record type `T`; 
    139141 
    140  field `y` is hidden altogether. 
     142  The existence of field `y` is hidden altogether. 
    141143 
    142144If you say: 
     
    150152then you are exporting the `x` field within record type `T`, but __not__ the field selector `x` (nor the generated type 'peg' `Proxy_x`). 
    151153 
    152 Type `T` and field label `x` are exported, but not data constructor `MkT`, so `x` is unusable. 
    153  
    154 The existence of field `y` is hidden altogether. 
     154Type `T` and field label `x` are exported, but not data constructor `MkT`, so `x` is (almost) unusable. (It can be used to update an existing record (without changing its record constructor) using syntax: `r{ x = 57 }`.) 
     155 
     156  The existence of field `y` is hidden altogether. 
    155157 
    156158 
     
    161163{{{ 
    162164    case r of { 
    163      Cust_Price {unit_Price, ..} 
    164           -> Cust_Price {unit_Price = unit_Price * 1.05, .. } 
    165     }         -- increases Price by 5% 
     165      Cust_Price {unit_Price, ..}    -> Cust_Price {unit_Price = unit_Price * 1.05, .. } 
     166      }                                          -- increases Price by 5% 
    166167}}} 
    167168(This uses ‑XDisambiguateRecordFields, -XRecordWildCards and ‑XNamedFieldPuns -- all mature GHC extensions.) 
     
    184185    set (undefined :: Proxy_unit_Price) (72 :: Int) myPrice 
    185186}}} 
    186 [See <DORF -- Implementor's view> for what the Proxy is doing.] 
     187[See [wiki:Records/DeclaredOverloadedRecordFields/ImplementorsView DORF -- Implementor's view] for what the Proxy is doing.] 
    187188 
    188189Normal type inference/instance resolution will find the record type for `myPrice`, and therefore the correct instance to apply the update. 
     
    192193    myCustNA { firstName = "Fred", lastName = "Dagg" } 
    193194}}} 
    194 [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.] 
     195    [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.] 
    195196 
    196197Some discussion threads have argued that Haskell's current record update syntax is awkward. The DORF proposal is to implement field update using a polymorphic function. Once this is implemented, alternative syntax could be explored, providing it desugars to a call to `set`.