Changes between Version 4 and Version 5 of Records/OverloadedRecordFields/Design


Ignore:
Timestamp:
Apr 22, 2014 10:01:33 AM (12 months ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Design

    v4 v5  
    161161These problems have already been [wiki:Records/OverloadedRecordFields/SORF/#Recordupdates described in some detail]. In the interests of doing something, even if imperfect, the overloaded-record-field design works as follows: 
    162162  
    163  * The traditional record update syntax supportx only non-overloaded update (that is, update of a unique known record type).  
    164  
    165  * Where overloading mean that the fields alone do not determine the data type being updated, a type signature may be required. For example, 
     163 * The traditional record update syntax `r { f1=e2, ..., fn=en }` supports only non-overloaded update; that is, update of a unique known record type.  
     164 
     165 * If there is only one data type that has all the fields  `f1` .. `fn` mentioned in the update, then that is the data type to be updated. 
     166 
     167 * If more than one data type has all those fields, a type signature may be used to disambiguate. For example, 
    166168{{{ 
    167169e { x = t } 
    168170}}} 
    169   currently relies on the name `x` to determine the datatype of the record. If this is ambiguous, a type signature can be given either to `e` or to the whole expression. Thus either 
     171  currently relies on the name `x` to determine the datatype of the record. If this is ambiguous, a type signature can be given either to `e` or to the whole expression (but nowhere else). Thus either 
    170172{{{ 
    171173  e :: T Int { x = t }