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


Ignore:
Timestamp:
Aug 11, 2013 5:07:51 AM (2 years 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.