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


Ignore:
Timestamp:
Feb 21, 2012 3:40:51 AM (3 years ago)
Author:
guest
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields/COmpareSORF

    v6 v7  
    1919 
    2020'''Wild afterthought:'''  
    21  * DORF __does__ need to apply module control/representation hiding to the field selector function. 
    22  * But if that's controlled, perhaps it doesn't need to control the Proxy type(?) 
     21 * DORF __does__ need to apply module control/representation hiding to the __field selector function__. 
     22 * But if that's controlled, perhaps it __doesn't__ need to control the Proxy type(?) 
    2323 * (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.) 
    2424 * Perhaps we could use Kinds instead, and ''take advantage of'' the __in__ability to control their scope: 
     
    3434                                                                 -- field type same as the function's result 
    3535}}} 
    36 makes customer_id available as a field label. (That is, the record constraint is __not__ added by the compiler.) 
     36    makes customer_id available as a field label. (That is, the record constraint is __not__ added by the compiler, you must put it explicitly.) 
    3737 
    38     (The compiler still needs to generate the binding for `customer_id = get` -- assuming proxy argument not needed.) 
     38    (The compiler still needs to generate the binding for `customer_id = Library.Has.get` -- eta-reduced, because I'm assuming the proxy/Kind argument is not needed.) 
    3939 
    4040    [Phew! avoided a reserved word.] 
    4141 
    42     Note that declaration is different to something like: 
     42    [I'm liking this, it's getting more minimal: If you don't want field selector functions, don't declare them. The instances for `Has/get/set` (generated from the record decl) don't need them, only the 'peg' provided by the Kind. Occam's razor rules! 
     43 
     44    Perhaps we then provide something like [wiki:Records/DeclaredOverloadedRecordFields/PolyRecordPattern Polymorphic Record Pattern] as an alternative record access mechanism??] 
     45 
     46    Note that declaration for customer_id is different to something like: 
    4347{{{ 
    4448        fullName :: r{ firstName, lastName :: String } => r -> String   -- yes, an explicit record constraint, 
     
    4650                                                                 -- field type not nec. same as the function's result 
    4751}}} 
    48  
     52    The programmer must provide a binding. 
    4953 
    5054 
     
    5660=== Higher Rank Types and Type Functions === 
    5761 
    58 DORF follows SORF in using a "functional-dependency-like mechanism (but using equalities) " to manage the type inference for Has/get/set. 
     62DORF follows SORF in using a "functional-dependency-like mechanism (but using equalities) " to manage the type inference for `Has/get/set`. 
    5963 
    6064=== Virtual record selectors ===