[GHC] #1401: otherwise ambiguous field names shouldn’t be treated as ambiguous when the data constructor is known

[GHC]

#1401: otherwise ambiguous field names shouldn’t be treated as ambiguous when
the data constructor is known
-----------------------------------------+----------------------------------
  Reporter:  g9ks157k at acme.softbase.org  |          Owner:         
      Type:  feature request             |         Status:  new    
  Priority:  normal                      |      Milestone:         
 Component:  Compiler                    |        Version:  6.6.1  
  Severity:  normal                      |       Keywords:         
Difficulty:  Unknown                     |             Os:  Unknown
  Testcase:                              |   Architecture:  Unknown
-----------------------------------------+----------------------------------
Consider these three module definitions:
 {{{
 module A where
     data A = A { label :: Char }
 }}}
 {{{
 module B where
     data B = B { label :: Char }
 }}}
 {{{
 module X where
     import A
     import B

     a = A { label = 'a' }

     b = B { label = 'b' }

     f (A { label = a }) (B { label = b }) = (a,b)
 }}}
 GHC currently treats all the occurences of {{{label}}} in module {{{C}}}
 as ambiguous thereby conforming to the Haskell 98 standard.  However, in
 all these cases there is only one field to which {{{label}}} can refer
 since the data constructor is known.  So it should be possible to let GHC
 treat the above code as legal by using a certain compiler option.  This
 would make the use of Haskell 98 records much more comfortable in certain
 cases.  Fields in different data types could be named equally if they
 denote similar concepts without forcing the user of the data types to
 qualify the field names over and over again.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1401>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
-------------- next part --------------
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs