[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:8 goldfire]:
 > But I do think my proposal answers Simon's first point: the programmer
 says explicitly what should be included by any import of a datatype. This
 choice is checked in my proposal, but I don't imagine that would be a
 challenge to implement. The interface file would indicate what pattern
 synonyms are included with a datatype. It all doesn't seem very
 complicated.
 >
 > As for smart constructors: I think that pattern synonyms subsume
 traditional "smart constructors". They should really be pattern synonyms
 now! With the change proposed in this ticket, clients might not even know
 the difference between a real constructor and a smart one.
 >
 > Here might be a motivation and a design principle for this feature: a
 library should be able to refactor a concrete data type without affecting
 client code. This refactoring would require exporting pattern synonyms
 mimicking the old behavior. But it's conceivable a client would never
 know.

 I agree on all accounts. We should strive to enable client code to be
 oblivious to library refactorings.

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