[GHC] #14307: Nonexistent constructor name + NamedFieldPuns + DuplicateRecordFields can cause ambiguous occurrence message

2 Oct 2017

      #14307: Nonexistent constructor name + NamedFieldPuns + DuplicateRecordFields can
cause ambiguous occurrence message
-------------------------------------+-------------------------------------
           Reporter:  mgsloan        |             Owner:  (none)
               Type:  feature        |            Status:  new
  request                            |
           Priority:  low            |         Milestone:
          Component:  Compiler       |           Version:  8.2.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 This is a minor issue with error message clarity. I was confused for a few
 minutes because in a more complicated example I did not see the out of
 scope error, and was instead focused on the ambiguity error.

 {{{
 {-# LANGUAGE DuplicateRecordFields #-}
 {-# LANGUAGE NamedFieldPuns #-}

 data A = A { field :: Int }
 data B = B { field :: Int }

 f :: A -> Int
 f C { field } = field
 }}}

 yields

 {{{
 duplicate_records_bug.hs:8:3: error:
     Not in scope: data constructor ‘C’
   |
 8 | f C { field } = field
   |   ^

 duplicate_records_bug.hs:8:7: error:
     Ambiguous occurrence ‘field’
     It could refer to either the field ‘field’,
                              defined at duplicate_records_bug.hs:5:14
                           or the field ‘field’, defined at
 duplicate_records_bug.hs:4:14
   |
 8 | f C { field } = field
   |       ^^^^^
 }}}

 I actually think it would make sense to allow ambiguous identifiers in
 field puns even if DuplicateRecordFields is not enabled.  This makes
 sense, because for an unambiguous constructor, a particular field name is
 always unambiguous.  So, that might be another way to frame this issue:
 Should ambiguous field identifiers always be allowed in puns?

 In particular, this would make things more consistent with
 RecordWildCards, which does not care if the field names shadow anything
 that is in scope / other field names.

 I realize that broadening the code allowed by NamedFieldPuns could lead to
 issues where code written for newer GHC versions does not work with older
 GHC versions.  This certainly will not change the meaning of older code.
 What's the policy on this?

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14307
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler