[GHC] #14307: Nonexistent constructor name + NamedFieldPuns + DuplicateRecordFields can cause ambiguous occurrence message
GHC
ghc-devs at haskell.org
Mon Oct 2 21:35:30 UTC 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
More information about the ghc-tickets
mailing list