Changes between Version 4 and Version 5 of Records/DeclaredOverloadedRecordFields/NoMonoRecordFields


Ignore:
Timestamp:
Aug 11, 2013 5:07:51 AM (23 months ago)
Author:
AntC
Comment:

Change name of the flag, per Adam's work on SORF, and SimonM's q on the ticket

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields/NoMonoRecordFields

    v4 v5  
    11 
    2 == No Mono Record Fields == 
     2== No Record Selector Functions == 
    33 
    44This proposal is a precursor to overloaded record fields. It's also a modest step towards freeing up the namespace, without in any way pre-judging how the 'narrow namespace issue' might get addressed. Ticket #5972. 
    55 
    66 
    7 There is to be a compiler flag '''-XNoMonoRecordFields'''. (Default value '''‑XMonoRecordFields''', to give H98 behaviour.) 
     7There is to be a compiler flag '''-XNoRecordSelectorFunctions'''. (Default value '''‑XRecordSelectorFunctions''', to give H98 behaviour.) 
    88 
    9 `-XNoMonoRecordFields` suppresses creating the field selector function from the field name in a record-style data declaration. 
     9`-XNoRecordSelectorFunctions` suppresses creating the field selector function from the field name in a record-style data declaration. 
    1010 
    1111Suppressing the function frees up the namespace, to be able to experiment with various record/field approaches -- including the 'cottage industry' of Template Haskell solutions. 
     
    1313In particular, this means we can declare more than one record type within a module using the same field name. 
    1414 
    15 `-XNoMonoRecordFields` implies `-XDisambiguateRecordFields` -- otherwise the only way to access record fields would be positionally. It also implies `‑XNamedFieldPuns` and `‑XRecordWildCards` to support field access and update. (IMHO, suppressing the field selector function should always have been part of `-XDisambiguateRecordFields`. I'm by no means the first to make that observation.)  
     15`-XNoRecordSelectorFunctions` implies `-XDisambiguateRecordFields` -- otherwise the only way to access record fields would be positionally. It also implies `‑XNamedFieldPuns` and `‑XRecordWildCards` to support field access and update. (IMHO, suppressing the field selector function should always have been part of `-XDisambiguateRecordFields`. I'm by no means the first to make that observation.)  
    1616 
    1717 * Note that the field name is still valid within the scope of a pattern match, or record update inside the `MkT{...}` explicit constructor syntax. 
     
    2828If you say: 
    2929{{{ 
    30 {-# OPTIONS_GHC -XNoMonoRecordFields                      #-} 
     30{-# OPTIONS_GHC -XNoRecordSelectorFunctions              #-} 
    3131module M( T( x ) )       where 
    3232    data T = MkT { x, y :: Int } 
     
    3535type `T` and field label `x` are exported, but not data constructor `MkT`, so `x` is unusable. 
    3636 
    37 (Without the `‑XNoMonoRecordFields` flag, field selector function `x` would be exported.) 
     37(Without the `‑XNoRecordSelectorFunctions` flag, field selector function `x` would be exported.) 
    3838 
    39 There's an effect on '''importing''' modules even if they don't set `-XNoMono...`, so that they are generating selector functions for record types they declare: 
     39There's an effect on '''importing''' modules even if they don't set `-XNoRecord...`, so that they are generating selector functions for record types they declare: 
    4040 
    4141 * The record types imported do not have field selector functions, so compilation must not generate code to (try to) use them.