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


Ignore:
Timestamp:
Apr 22, 2014 9:57:52 AM (11 months ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Design

    v3 v4  
    159159 * records may include higher-rank components. 
    160160 
    161 These problems have already been [wiki:Records/OverloadedRecordFields#Recordupdates described in some detail]. In the interests of doing something, even if imperfect, the traditional record update syntax will support only non-overloaded update (that is, update of a unique known record type). Where overloading mean that the fields alone do not determine the type being updated, a type signature may be required. For example, 
     161These 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: 
     162  
     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, 
    162166{{{ 
    163167e { x = t } 
    164168}}} 
    165 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 
     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 
    166170{{{ 
    167171  e :: T Int { x = t } 
    168172}}} 
    169 or 
     173  or 
    170174{{{ 
    171175  e { x = t } :: T Int 
    172176}}} 
    173 will be accepted. (Really only the type constructor is needed, whereas this approach requires the whole type to be specified, but it seems simpler than inventing a whole new syntax.) 
     177  will be accepted. (Really only the type constructor is needed, whereas this approach requires the whole type to be specified, but it seems simpler than inventing a whole new syntax.) 
    174178 
    175179