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


Ignore:
Timestamp:
Jul 1, 2013 12:36:14 PM (10 months 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