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


Ignore:
Timestamp:
Apr 22, 2014 9:57:52 AM (16 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