[GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation

[GHC]

#10653: PatternSynonyms should be imported/exported as part of the wildcard
notation
-------------------------------------+-------------------------------------
        Reporter:  gridaphobe        |                   Owner:
            Type:  feature request   |                  Status:  new
        Priority:  normal            |               Milestone:  7.12.1
       Component:  Compiler          |                 Version:  7.11
      Resolution:                    |                Keywords:  pattern
                                     |  synonyms
Operating System:  Unknown/Multiple  |            Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by goldfire):

 gridaphobe's interpretation of my proposal is more accurate. I do mean to
 allow the reassociation of pattern synonyms in any module. This means that
 you have to "chase the import chain" to figure out what `T(..)` means. But
 this is ''already'' true!

 {{{
 module A ( T(MkT1,MkT2) ) where data T = MkT1 | MkT2 | MkT3
 module B ( T(..) ) where import A ( T(MkT1) )
 module C ( T(..) ) where import B ( T(..) )
 module D where import C ( T(..) )
 }}}

 Figuring out what is in scope in `D` requires chasing a module chain. My
 proposal makes this no different.

 Indeed, I believe (if we drop the redundant `pattern` keyword in the
 parenthesized list after a datatype) my proposal makes it so that data
 constructors are no longer privileged at all. For example:

 {{{
 module E ( T( Pat ), pattern Mk ) where
 data T = Mk
 pattern Pat = Mk
 }}}

 This means that `Pat` is imported with `T(..)` but `Mk` has to be imported
 separately. Is this confusing? Perhaps. But perhaps it is also sensible if
 done for backward compatibility.

 I'm not really against putting all of this in the datatype declaration
 instead of in an export list. (Actually, I quite like `data T = PublicMk |
 abstract PrivateMk` or similar.) But aiming to avoid module chasing to
 understand `T(..)` is a red herring.

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