Changes between Version 5 and Version 6 of Records/DeclaredOverloadedRecordFields/COmpareSORF


Ignore:
Timestamp:
Feb 21, 2012 3:18:33 AM (4 years ago)
Author:
guest
Comment:

pretty up the linking, add wilder afterthought -- AntC

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields/COmpareSORF

    v5 v6  
    22= DORF -- comparison to SORF (and to TDNR) =
    33
    4 This is a brief point-by-point comparison to
    5 http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
     4This is a brief point-by-point comparison to [wiki:Records/OverloadedRecordFields Simple Overloaded Record Fields]
    65
    76I'll only dwell on where the DORF proposal differs.
     
    2322 * But if that's controlled, perhaps it doesn't need to control the Proxy type(?)
    2423 * (In fact, the Proxy type is a bit of an annoyance, with a shadowy existence just out of sight from the application programmer, except for the need to export/import it.)
    25  * Perhaps we could use Kinds instead, and take advantage of the inability to control their scope:
     24 * Perhaps we could use Kinds instead, and ''take advantage of'' the __in__ability to control their scope:
    2625   * Kinds could be just used, not declared.
    2726   * They could be `String` Kinds or some more abstract/compact/hidden representation.
     27   * There'd be no issues with name clashes, because different modules using the same named field could ''share'' the Kind; but have 'private' namespaces for the field selector function.
     28
     29'''Wilder aftererthought:'''
     30Perhaps then we could avoid the need for the new `fieldLabel`, instead this declaration:
     31{{{
     32    customer_id :: r{ customer_id :: Int } => r -> Int           -- explicit record constraint
     33                                                                 -- field name same as the declared function
     34                                                                 -- field type same as the function's result
     35}}}
     36makes customer_id available as a field label. (That is, the record constraint is __not__ added by the compiler.)
     37
     38    (The compiler still needs to generate the binding for `customer_id = get` -- assuming proxy argument not needed.)
     39
     40    [Phew! avoided a reserved word.]
     41
     42    Note that declaration is different to something like:
     43{{{
     44        fullName :: r{ firstName, lastName :: String } => r -> String   -- yes, an explicit record constraint,
     45                                                                 -- but: field name(s) different to the declared function
     46                                                                 -- field type not nec. same as the function's result
     47}}}
     48
    2849
    2950
     
    5273=== Representation hiding ===
    5374
    54 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.
     75See the discussion under [wiki:Records/DeclaredOverloadedRecordFields/NoMonoRecordFields 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.
    5576
    5677=== Syntax - The dot notation ===
    5778
    58 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>
     79DORF 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 [wiki:Records/DeclaredOverloadedRecordFields/DotPostfix Dot as Postfix Function Apply]
    5980
    6081=== Syntax - Syntactic sugar for `Has` ===
     
    6687DORF 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.
    6788
    68 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.)
     89SPJ 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.)
    6990
    7091To 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