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


Ignore:
Timestamp:
Apr 22, 2014 10:36:27 AM (16 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):