Changes between Version 2 and Version 3 of Records/DeclaredOverloadedRecordFields/NoMonoRecordFields


Ignore:
Timestamp:
Mar 27, 2012 9:17:03 PM (3 years ago)
Author:
AntC
Comment:

Clarify purpose, use cases

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields/NoMonoRecordFields

    v2 v3  
    22== No Mono Record Fields ==
    33
    4 This proposal is a precursor to overloaded record fields.
     4This 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.
     5
    56
    67There is to be a compiler flag '''-XNoMonoRecordFields'''. (Default value '''‑XMonoRecordFields''', to give H98 behaviour.)
     
    1011Suppressing the function frees up the namespace, to be able to experiment with various record/field approaches -- including the 'cottage industry' of Template Haskell solutions.
    1112
    12 `-XNoMonoRecordFields` implies `-XDisambiguateRecordFields` -- otherwise the only way to access record fields is 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.)
     13In particular, this means we can declare more than one record type within a module using the same field name.
    1314
    14 Note that the field name is still valid within the scope of a pattern match, or record update inside the `{...}` constructor syntax.
     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.)
     16
     17 * Note that the field name is still valid within the scope of a pattern match, or record update inside the `MkT{...}` explicit constructor syntax.
     18 * But record update won't work, because the field name alone doesn't uniquely identify the record type.[[BR]](That is, the syntax with a record or expression prefix to the braces `e{ x = True }` -- there might be multiple record types declared in the module with field name x.)
    1519
    1620Example use case: http://www.haskell.org/pipermail/haskell-cafe/2009-May/061879.html (referred from an old Wiki discussion on TDNR http://www.haskell.org/haskellwiki/TypeDirectedNameResolution .)
     21
     22See also thread starting: http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021433.html (and continuing through February), which initially considers nested modules as an approach for namespacing.
    1723
    1824
     
    3238(Without the `‑XNoMonoRecordFields` flag, field selector function `x` would be exported.)
    3339
     40There'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:
     41
     42 * The record types imported do not have field selector functions, so compilation must not generate code to (try to) use them.
     43 * But other uses of the field name must still work: (pattern matching, punning and wildcards, record creation using explicit data constructor (and `-XDisambiguateRecordFields`).
     44 * Record update `e{ x = True }` won't work.
     45