Changes between Version 10 and Version 11 of Records/OverloadedRecordFields/Design


Ignore:
Timestamp:
Apr 22, 2014 10:36:27 AM (12 months ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Design

    v10 v11  
    356356== Design choices == 
    357357 
    358 === Scope issues, or, why we miss dot === 
    359  
    360 Consider the following example: 
     358=== Scope issues, or, why we miss dot notation === 
     359 
     360In some ways it would be very desirable to support dot notation.  Consider the following example: 
    361361 
    362362{{{ 
     
    367367Q1. What happens if `g` is not in scope? 
    368368 
    369 A. The code gives an error. This is where dot-notation (or another syntactic form marking a field name) is better: `f x = x.g + 1` can work even if `g` is not in scope. Observe that something similar happens with implicit parameters: `f y = y + ?x` works even if `x` is not in scope, and introduces a new constraint `(?x :: Int)`.  
     369A. The code gives an error (`g` is not in scope).  We can't write record-manipulating functions unless there is at least one records in scope with that field name (`g` in this case).   
     370 
     371This is where dot-notation (or another syntactic form marking a field name) is better: `f x = x.g + 1` can work even if `g` is not in scope. Observe that something similar happens with implicit parameters: `f y = y + ?x` works even if `x` is not in scope, and introduces a new constraint `(?x :: Int)`.  
    370372 
    371373Q2. What if we add `data T = MkT { g :: Char }`? 
     
    378380 
    379381 
    380 === Syntax for record projections === 
     382=== Alternatives to dot-notation === 
    381383 
    382384An advantage of distinguishing record projections syntactically (as in `x.g`) is that `g` 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. We could consider using an operator less controversial than dot (for example, `#` has been suggested):