Changes between Version 9 and Version 10 of Records/TypePunningDeclaredOverloadedRecordFields
- Timestamp:
- 03/11/12 22:06:08 (15 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Records/TypePunningDeclaredOverloadedRecordFields
v9 v10 3 3 == Thumbnail Sketch == 4 4 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: 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). This proposal is in the DORF 'stable', but sufficiently different it is worth making it a separate proposal. 6 7 Specifically each sharing field name is overloaded, and there is a Type with the same name (upshifted) so that: 6 8 * __Within the same module__, many record types can be declared to share the field name. 7 9 * The field name can be exported so that records __in other modules__ can share it. … … 15 17 In case of 'unintended' clash (another module using the same name 'by accident'), usual H98 controls apply to protect encapsulation and representation hiding. 16 18 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:19 This 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: 18 20 * The field name overloading is implemented through usual class and instance mechanisms. 19 21 * 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.) … … 39 41 }}} 40 42 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 short cuts, but still supporting H98-style declaring field names within the record decl for backwards compatibility.43 TPDORF 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. 42 44 43 45 Here is the `Has` class with instances for the above Customer record, and examples of use: … … 72 74 type instance GetResult Customer FirstName = String -- specific to this record/field 73 75 -- type instance SetResult Customer FirstName = Customer -- not needed/already declared above 74 76 -- (but OK because overlaps and same result) 75 77 76 78 myCust :: Customer -- usual record decl 77 ... myCust{ customer_id = 27, firstName = "Fred" } 79 ... myCust{ customer_id = 27, firstName = "Fred" } ... -- **polymorphic** record update, no data constr 78 80 ... (customer_id myCust) ... -- field selection is func apply, or: 79 81 ... myCust.customer_id ... -- dot notation is sugar for reverse func apply … … 89 91 * 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? 90 92 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. 92 94 93 95 To generate the correct field selector function, there is to be a new deriving class; and for record decls a shorthand:
