[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 gridaphobe):

 Replying to [comment:10 simonpj]:
 >  * In the defining module of a data type (''and nowhere else'') you can
 list pattern synonyms in the export list thus `T( ..., pattern A1 )`, and
 that permanently associates `A1` with `T`.

 Hmm, I understood Richard's proposal to mean that ''any'' module can
 associate pattern synonyms with a data type in the export list. In this
 case the association would not be permanent, as client modules could
 always choose to break the association or associate different pattern
 synonyms, by changing their export list.

 So in my interpretation you would have to to chase the import chain to
 figure out precisely what `T(..)` means, and there would be no "maximal"
 meaning. I can see the argument against that.

 If we go with your interpretation and say that ''only'' the defining
 module can associate pattern synonyms with a data type, I agree that it
 would be better to declare the association alongside the data type.

 I guess the real question is this: do we want to allow modules to
 associate pattern synonyms with data types that they have imported from
 somewhere else?

 I can see one situation where this would be handy. Suppose a package `p`
 changes one of its core data types, but does not export pattern synonyms
 to provide backwards compatibility. A client could write a new package
 `p-compat` that provides the necessary patterns and associates them with
 `p`s data types, thus seamlessly recreating the old API.

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