#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