[GHC] #4479: Implement TDNR

[GHC]

#4479: Implement TDNR
-------------------------------------+-------------------------------------
        Reporter:  gidyn             |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  low               |            Milestone:
       Component:  Compiler (Type    |              Version:  7.5
  checker)                           |
      Resolution:                    |             Keywords:  ORF
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by adamgundry):

 * keywords:   => ORF


Comment:

 gidyn, thanks for starting a new proposal. Your effort to push this along
 is appreciated!

 I think your idea for doing TDNR without any syntax can indeed be seen as
 a proper generalization of `DuplicateRecordFields`, which permits
 syntaxless TDNR in the special case of record field names.

 Unfortunately I tend to agree with AntC that the proposal needs more
 precision. We want to avoid the situation that the programs GHC accepts
 depend on implementation details of the type-checker. This means that we
 need a (possibly hypothetical) declarative specification of what the
 typing rules should be for ambiguous names.

 Moreover, it's probably best if introducing or removing an ambiguity
 doesn't lead to different valid types for the same program. This implies
 that disambiguation should use information gleaned from the existing
 bidirectional typing rules, but not do additional inference. This
 requirement is why approaches based on deferring name resolution to the
 constraint solver, like ORF's magic classes, use a syntactic cue to
 indicate that the identifier should be treated specially.

 These are tough goals to meet, and explain why the current
 `DuplicateRecordFields` is quite conservative in what it will accept (see
 #11343). No doubt it is possible to do something more general, but it's
 hard to specify, let alone implement. I think that is part of the reason
 that TDNR has languished over the years.

 [AntC already mentioned this on the wiki page, but for future reference,
 this mailing list thread is very relevant:
 https://mail.haskell.org/pipermail/glasgow-haskell-
 users/2016-May/026225.html]

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