|
|
## No Mono Record Fields
|
|
|
|
|
|
|
|
|
This proposal is a precursor to overloaded record fields.
|
|
|
This 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.
|
|
|
|
|
|
|
|
|
There is to be a compiler flag **-XNoMonoRecordFields**. (Default value **‑XMonoRecordFields**, to give H98 behaviour.)
|
... | ... | @@ -11,14 +11,21 @@ There is to be a compiler flag **-XNoMonoRecordFields**. (Default value **‑XMo |
|
|
|
|
|
Suppressing the function frees up the namespace, to be able to experiment with various record/field approaches -- including the 'cottage industry' of Template Haskell solutions.
|
|
|
|
|
|
`-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.)
|
|
|
|
|
|
In particular, this means we can declare more than one record type within a module using the same field name.
|
|
|
|
|
|
Note that the field name is still valid within the scope of a pattern match, or record update inside the `{...}` constructor syntax.
|
|
|
`-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.)
|
|
|
|
|
|
- Note that the field name is still valid within the scope of a pattern match, or record update inside the `MkT{...}` explicit constructor syntax.
|
|
|
- But record update won't work, because the field name alone doesn't uniquely identify the record type.
|
|
|
(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.)
|
|
|
|
|
|
|
|
|
Example use case: [ http://www.haskell.org/pipermail/haskell-cafe/2009-May/061879.html](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](http://www.haskell.org/haskellwiki/TypeDirectedNameResolution) .)
|
|
|
|
|
|
|
|
|
See also thread starting: [ http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021433.html](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.
|
|
|
|
|
|
### Import/Export and Representation hiding
|
|
|
|
|
|
|
... | ... | @@ -39,3 +46,10 @@ type `T` and field label `x` are exported, but not data constructor `MkT`, so `x |
|
|
|
|
|
|
|
|
(Without the `‑XNoMonoRecordFields` flag, field selector function `x` would be exported.)
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
- The record types imported do not have field selector functions, so compilation must not generate code to (try to) use them.
|
|
|
- But other uses of the field name must still work: (pattern matching, punning and wildcards, record creation using explicit data constructor (and `-XDisambiguateRecordFields`).
|
|
|
- Record update `e{ x = True }` won't work. |