[GHC] #10027: Importing constructor of associated data type fails

[GHC]

#10027: Importing constructor of associated data type fails
-------------------------------------+-------------------------------------
        Reporter:  lspitzner         |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.8.4
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |  constructor import associated data
 Type of failure:  None/Unknown      |  type
      Blocked By:                    |            Architecture:
 Related Tickets:                    |  Unknown/Multiple
                                     |               Test Case:
                                     |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by lspitzner):

 The case without an export-list feels special-casy, but if i am not
 mistaken the problem is not restricted to it: It is impossible to
 explicitly export data constructors without exporting the data family as
 well:

 {{{#!hs
 module A where
   data family D a

 module B
   ( D ( DCon ) -- cannot not export D
   )
 where
   import A
   data Foo = Foo
   data instance D Foo = DCon
 }}}

 To me, the core of the issue seems to be that "D(DCon)" refers to __both__
 ''D'' and ''D.DCon''. Would it not make sense to weaken this? E.g. replace
 the relevant section in report2010:5.2 with:

 > * The form ''T'' names the type but not the constructors or field names.
 > * The form ''T(c1,…,cn)'', names the sum of:
 >    a) the type, but only if it is declared locally,
 >    b) the mentioned constructors or field names, which may be an empty
 list
 > * The abbreviated form ''T(..)'' names the same as ''T(c1,…,cn)'' where
 ''c1,…,cn'' is the full list of constructors/field names currently in
 scope (qualified or not)
 (i sneaked the "which may be an empty list" fix in; this seems to match
 what is implemented)

 This approach would next need to define how importing is handled, as
 "declared locally" does not make sense on import-side. I would propose to
 give it "grab all you can" semantics, i.e.

 > ''import B ( D ( DCon ) )'' imports ''DCon'', and ''D'' if it is
 exported by ''B''.

 Examples for the export:
 {{{#!hs
 module B
   ( D ( DCon ) -- only D.DCon
   )

 module B
   ( D          -- re-export the data family
   , D ( DCon ) -- D.DCon
   )
 }}}

 With this, the no-export-list case becomes trivial.

 How high would the risk of this breaking existing code be? Are there other
 disadvantages?

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