Changes between Version 9 and Version 10 of Records/TypePunningDeclaredOverloadedRecordFields


Ignore:
Timestamp:
Mar 12, 2012 5:06:08 AM (3 years ago)
Author:
AntC
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/TypePunningDeclaredOverloadedRecordFields

    v9 v10  
    33== Thumbnail Sketch == 
    44 
    5 This proposal is addressing the narrow issue of '''namespacing for record field names''' by allowing more than one record in the same module to share a field name. Furthermore, it is aiming at a more structured approach to higher-ranked type fields, so that they can be updated using the same surface syntax as for other fields. This actually means a less complex implementation (compared to DORF or SORF). Specifically each field name is overloaded, and there is a Type with the same name (upshifted) so that: 
     5This proposal is addressing the narrow issue of '''namespacing for record field names''' by allowing more than one record in the same module to share a field name. Furthermore, it is aiming at a more structured approach to higher-ranked type fields, so that they can be updated using the same surface syntax as for other fields. This actually means a less complex implementation (compared to DORF or SORF). This proposal is in the DORF 'stable', but sufficiently different it is worth making it a separate proposal. 
     6 
     7Specifically each sharing field name is overloaded, and there is a Type with the same name (upshifted) so that: 
    68 * __Within the same module__, many record types can be declared to share the field name. 
    79 * The field name can be exported so that records __in other modules__ can share it. 
     
    1517In case of 'unintended' clash (another module using the same name 'by accident'), usual H98 controls apply to protect encapsulation and representation hiding. 
    1618 
    17 This proposal introduces several new elements of syntax, all of which desugar to use well-established extensions of ghc. The approach is yet to be prototyped, but I expect that to be possible in ghc v 7.2.1. In particular: 
     19This proposal introduces several new elements of syntax (including some shorthands), all of which desugar to use well-established extensions of ghc. The approach is yet to be prototyped, but I expect that to be possible in ghc v 7.2.1. In particular: 
    1820 * The field name overloading is implemented through usual class and instance mechanisms. 
    1921 * Field selectors are ordinary functions named for the field (but overloaded rather than H98's monomorphic), so field selection is regular function application. (There is no need for syntactically-based disambiguation at point of use.) 
     
    3941}}} 
    4042 
    41 TPDORF makes a virtue of this punning. (So extend's H98's and `NamedFieldPuns` punning on the field name.) This allows for some syntactic shortcuts, but still supporting H98-style declaring field names within the record decl for backwards compatibility. 
     43TPDORF makes a virtue of this punning. (So extend's H98's and `NamedFieldPuns` punning on the field name.) This allows for some syntactic shorthands, but still supporting H98-style declaring field names within the record decl for backwards compatibility. 
    4244 
    4345Here is the `Has` class with instances for the above Customer record, and examples of use: 
     
    7274    type instance GetResult Customer FirstName     = String             -- specific to this record/field 
    7375    -- type instance SetResult Customer FirstName  = Customer           -- not needed/already declared above 
    74  
     76                                                                        -- (but OK because overlaps and same result) 
    7577 
    7678    myCust :: Customer                                                  -- usual record decl 
    77     ... myCust{ customer_id = 27, firstName = "Fred" }                  -- **polymorphic** record update, no data constr 
     79    ... myCust{ customer_id = 27, firstName = "Fred" } ...              -- **polymorphic** record update, no data constr 
    7880    ... (customer_id myCust) ...                                        -- field selection is func apply, or: 
    7981    ... myCust.customer_id ...                                          -- dot notation is sugar for reverse func apply 
     
    8991 * Possible '''downside:''' for non-`sharing` fields, what's the risk there's already a Type with the same name (upshifted) __and__ that the name is an 'accidental' clash? 
    9092 
    91     It is an error to be `sharing` a record field without there being a same-named type in scope. The desugar for the data decl would create the instance to use the Type, but then the instance would fail. 
     93    It is an error to be `sharing` a record field without there being a same-named Type in scope. The desugar for the data decl would create the instance to use the Type, but then the instance would fail. 
    9294 
    9395To generate the correct field selector function, there is to be a new deriving class; and for record decls a shorthand: