[GHC] #5972: option to suppress (Monomorphic) record selector functions

[GHC]

#5972: option to suppress (Monomorphic) record selector functions
-------------------------------------+-------------------------------------
        Reporter:  AntC              |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:
      Resolution:                    |             Keywords:  records
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by AntC):

 Thank you Adam for the implementation detail.

 Remember:
 * This ticket was raised 4+ years ago (strewth!) when there were huge
 debates raging about the "Records problem" and a great deal of nothing had
 been achieved. (It was even before PolyKinds and type-level Strings IIRC.)
 I wanted to free up some of the design space.
 * I am not an implementor, so what the ticket requests is in terms of an
 end-programmer's view.
 * My remarks just above (and back then) re field labels vs selectors are
 in terms of the language report [section 3.15]
    "[Field] Selectors are top level bindings ... This [name] shadowing
 only affects selector functions; in record construction (Section 3.15.2)
 and update (Section 3.15.3), field labels cannot be confused with ordinary
 variables."

 > When I read this ticket I didn't imagine that enabling this flag would
 allow duplicate field labels, ...

 No that wasn't the aim. I was merely aiming to avoid gobbling up the name
 space. DuplicateRecordFields is a different way to avoid it.

 > ... just suppress the generation of the field accessors.
 >
 > Anyway, this ticket was instructive because it showed how tightly
 intertwined the implementation is.

 Yes. Isn't it! I rather wish I hadn't found that out. We still seem a long
 way from a decent records system.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5972#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler