Changes between Version 14 and Version 15 of Records/DeclaredOverloadedRecordFields


Ignore:
Timestamp:
Feb 22, 2012 10:21:02 PM (3 years ago)
Author:
AntC
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields

    v14 v15  
    3838In data model design you'd typically go about identifying all the fields (types aka attributes) and putting them in a data dictionary. Then you'd construct your records from them. You might (possibly) put the data dictionary in a distinct module, for easy maintenance. But you'd certainly want all the customer-related records in the same module. So a data decl:
    3939{{{
    40     data Customer_NameAddress = Cust_NA { customer_id :: Int, ... }
     40    data Customer_NameAddress = Cust_NA{ customer_id :: Int, ... }
    4141}}}
    4242is __not__ declaring `customer_id`, it's __using__ (or instancing) an already-declared field for `customer_id`.
     
    138138}}}
    139139
     140
    140141=== Import/Export and Representation hiding ===
    141142
     
    210211    [There's a poor story to tell here in implementation terms: we split into two calls to `set`, one nested inside the other. It's wasteful to build the intermediate record. Worse, the two fields' types might be parametric in the record type or polymorphically related (perhaps one is a method to apply to the other), then we get a type failure on the intermediate record.]
    211212
     213Note that where there is a genuine business-as-usual name clash you'd need qualified names in polymorphic update syntax, as currently:
     214{{{
     215    someCust2 = someCust{ My.customer_id = 57, ... }
     216}}}
     217That is, there'd be no inference from the type of `someCust` to figure out which field label you're using. (That's because in general we can't infer the type of the expression prefixing the `{ ... }` update.)
     218
     219
    212220Some discussion threads have argued that Haskell's current record update syntax is awkward. The DORF proposal is to implement field update using a polymorphic function. Once this is implemented, alternative syntax could be explored, providing it desugars to a call to `set`.
    213221