Changes between Version 5 and Version 6 of Records/DeclaredOverloadedRecordFields


Ignore:
Timestamp:
Feb 17, 2012 11:15:04 PM (3 years ago)
Author:
guest
Comment:

further page splitting

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields

    v5 v6  
    77 * ''' DORF -- Application Programmer's view '''     (this page)
    88 * ''' [wiki:Records/DeclaredOverloadedRecordFields/ImplementorsView DORF -- Implementor's view] '''
    9  * ''' DORF -- Comparison to SORF '''
     9 * ''' [wiki:Records/DeclaredOverloadedRecordFields/CompareSORF DORF -- Comparison to SORF] '''
    1010 * ''' Dot as Postfix Funcion Apply '''   (optional syntactic sugar)
    1111
     
    196196
    197197
    198 
    199 ---------------------- DORF -- comparison to SORF ----------------
    200 
    201 This is a brief point-by-point comparison to
    202 http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
    203 
    204 I'll only dwell on where the DORF proposal differs.
    205 
    206 The 'Base Design' is very similar: a library class `Has', methods get/set, with an instance generated for each declared record/field. Field selection (either prefix per H98 or dot notation) is desugared to a call to the `get' method.
    207 
    208 The `String' type parameter to `Has', and Scope control
    209 
    210 DORF uses a Proxy type for the type/kind-level 'peg' on which to hang the instances. Using a Proxy is a superficial difference, and mostly for practical reasons -- I was building a proptotype in 7.2.1 (which doesn't have user-definable or `String' Kinds).
    211 
    212 There is, however, a significant difference on scoping/namespacing: the Proxy type (being a type) is bound by the usual module scoping, export/import and module qualification, etc. Are (`String') Kinds bound by module scope?
    213 
    214 The module namespacing in DORF is deliberate, and for exactly the same reason as namespacing in general: a different developer in a different module might 'accidentally' create a clashing name which is unrelated (that is, a name for a field or a record or both). As far as DORF is concerned, these are different names, so need the module name qualification.
    215 
    216 In contrast: "The [SORF] proposal ... doesn't allow label names to be scoped: if one module internally uses "field" as a label name then another module can break the abstraction by using the same string "field"." SPJ goes on to discuss a work-round which he sees as "ugly", and concludes "we need scoped instances". DORF does not need any innovations around instances or type inference.
    217 
    218 Should `get' have a Proxy argument?
    219 "This choice does not make a major difference either way." [SPJ]. DORF likewise doesn't care. The prototype does use a Proxy argument, because it's implemented using types not Kinds, and GHC doesn't (yet) have type application.
    220 
    221 
    222 Higher Rank Types and Type Functions
    223 DORF follows SORF in using a "functional-dependency-like mechanism (but using equalities) " to manage the type inference for Has/get/set.
    224 
    225 Virtual record selectors
    226 Are a valuable feature, and particularly valuable because they 'look' just like record field selectors. DORF supports them as ordinary (overloaded) functions, defined in terms of field selectors (so that their types are inferred to need the records/fields).
    227 Under DORF, virtual record selectors do not need `Has' instances, so don't run into the problem of what to do about the definition for `set'.
    228 (Perhaps DORF has a contrary problem: what if we do want a `set' for a virtual field? -- for example to update a fullName into firstName and lastName. There's food for thought in Wadler's original paper that led to View Patterns "Views: A way for pattern matching to cohabit with data abstraction" [1987], 4. "Viewing a complex number in cartesian and polar coordinates". We may want our implementation of complex to be abstract. We provide (pseudo-) fields to select the coordinates. Then they're ever-so like methods for an (abstract) object. Also we want the (pseudo-) fields to be updatable, which means we need an instance for Has/get/set for fields that are not explicit in the record.)
    229 Selectors as functions
    230 We need to support H98-style record selectors. One of the design objectives for DORF is that field selectors continue to be functions, just as H98. (The difference is that DORF's are overloaded whereas H98's are monomorphic.)
    231 You can use dot notation with H98 field selectors without changing the H98 record definition.
    232 
    233 Representation hiding
    234 See the discussion under <No Mono Record Fields>. SORF has an issue, because (in effect) it needs to control export of instances. "Solving this issue is important" [SPJ]. DORF doesn't have this issue, because the field selector is just a function, so the module system can control its visibility, as usual.
    235 Syntax - The dot notation
    236 DORF pretty much agrees with SORF, including in keeping it simple by not supporting part-applied dot. Note that DORF does not rely on dot notation whatsoever -- it's purely syntactic sugar for function application. See <Dot as Postfix Function Apply>
    237 Syntax - Syntactic sugar for `Has'
    238 SPJ is spot-on. DORF follows SORF.
    239 
    240 Record updates
    241 DORF follows SORF in having a `set' method within class `Has'. It's definition and instances are tricky, to support changing the type [**] of records/fields, and higher-ranked fields.
    242 SPJ is "not very happy with any of this" (that is, any of the SORF approach to field update). DORF has implemented record update using (admitted) hacks. DORF has tried to hide the implementation behind syntactic sugar (for the `Has' constraint), to make available some design space for improvements. (Including possibly the Alternative proposal using Quasifunctor.)
    243 To answer SPJ's question "what does e { x = True } mean if there are lots of "x" fields in scope? ": Under DORF, there is only a single "x" in scope(overloaded to appear in many record types). So
    244    e { x = True } :: r{ x :: Bool} => r
    245 [**] changing the type of records fields at update seems to be a required feature. DORF has implemented it to be compatible with H98, but this adds considerable complexity. We avoid the question of whether it's desirable.
    246 DORF does not have the issues trying to support or avoid `set' for virtual fields, because those are not defined using `Has'. (Source code that attempts to update via them, such as :
    247     myCust { fullName = "Fred Dagg" }
    248 will get type failure:
    249     no instance Has Customer_NameAddress Proxy_fullName String
    250 or earlier still (if we implement DORF using proxies):
    251     no type Proxy_fullName
    252 
    253 
    254 Relationship to Type Directed Name Resolution [TDNR]
    255 DORF is in some ways a reversion to something closer to TDNR (especially dot notation "works with any function"). DORF, SORF and TDNR all use a `Has' constraint, generated from the record/field declaration.
    256 Unlike TDNR, DORF has no special syntax to trigger name resolution. (DORF's dot postfix notation is just syntactic sugar for function application, and name 'resolution' is type-directed only in the sense of familiar instance resolution.)
    257 But the crucial difference is that TDNR still treats multiple declarations of the same field name (in different record types) as being different names. DORF treats these as multiple instances of the _same_ name.
    258198
    259199--------------- Dot as Postfix Function Apply --------------------