wiki:Records/DeclaredOverloadedRecordFields/NoMonoRecordFields

Version 2 (modified by AntC, 2 years ago) (diff)

Add use case

No Mono Record Fields

This proposal is a precursor to overloaded record fields.

There is to be a compiler flag -XNoMonoRecordFields. (Default value ‑XMonoRecordFields, to give H98 behaviour.)

-XNoMonoRecordFields suppresses creating the field selector function from the field name in a record-style data declaration.

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.)

Note that the field name is still valid within the scope of a pattern match, or record update inside the {...} constructor syntax.

Example 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 .)

Import/Export? and Representation hiding

Since there is no field selector function created, it can't be exported or imported.

If you say:

{-# OPTIONS_GHC -XNoMonoRecordFields                      #-}
module M( T( x ) )       where
    data T = MkT { x, y :: Int }

then the existence of field y is hidden; type T and field label x are exported, but not data constructor MkT, so x is unusable.

(Without the ‑XNoMonoRecordFields flag, field selector function x would be exported.)