Changes between Version 17 and Version 18 of Records/OverloadedRecordFields/Plan


Ignore:
Timestamp:
Jul 1, 2013 12:36:14 PM (2 years ago)
Author:
adamgundry
Comment:

introducing field names

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Plan

    v17 v18  
    209209
    210210
     211=== Introducing field names ===
     212
     213An advantage of distinguishing record projections syntactically (as in `e.x`) is that `x` is always treated as a record field, regardless of what is in scope. This allows better separation of concerns, as functions that manipulate records can be defined abstractly rather than referring to particular datatypes.
     214
     215One workaround is to define unused types with the appropriate field names. This is slightly odd, and we might consider adding a new declaration form '''field''' `x`, which declares `x` as a record field that is always polymorphic, rather like the function declaration
     216
     217{{{
     218x :: r { x :: t } => r -> t
     219x = getFld
     220}}}
     221
     222but with the property that it will not clash with actual `x` fields.
     223
     224
    211225== Example of constraint solving ==
    212226