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


Ignore:
Timestamp:
Apr 22, 2014 10:01:33 AM (17 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 }