[GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context

[GHC]

#8581: Pattern synonym used in an expression context could have different
constraints to pattern used in a pattern context
-------------------------------------+-------------------------------------
        Reporter:  cactus            |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:
      Resolution:                    |             Keywords:
                                     |  PatternSynonyms
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 While we're at this, there is another outstanding issue: a pattern synonym
 type should give some indication of the synonym's directionality.

 I think there are two quite separable questions here:
 1. What features do we want GHC to support?
 2. What concrete syntax will support those features?

 Let's tackle these design questions in order.

 For (1) the fundamental question seems to be:

 1a. What relationship between the expression-type and the pattern-type do
 we wish to require?

 Possible answers:
 A. None at all.
 B. The types have the same structure, but perhaps different constraints.
 C. Something in between. For example, both have to have the same arity
 and/or the same head of the result type.

 Personally, I think only A or B is defensible here. Furthermore, I favor
 A. History has shown that Haskellers like as much freedom to explore as
 possible. There is no type safety issue at hand. So let's give people more
 rope. I wager the idea of one symbol having two different types (in two
 very-easy-to-distinguish contexts) is less confusing than, say, kind
 polymorphism.

 Now, onto design point (2). I wonder if it's helpful to think of pattern
 synonym types as a `(PatternType, Maybe Type)`. The first component is a
 pattern-type, with its separate provided and required contexts, etc. It
 classifies the pattern synonym when used as a pattern. The second
 component is (perhaps) the type of the pattern synonym when used as an
 expression. This component is missing, naturally, when the synonym is
 unidirectional. Note that this component (when it exists) is just a normal
 type.

 Typically, the second component can be constructed in a straightforward
 manner from the first (if the synonym is bidirectional). But it need not
 be.

 Thinking along these lines, I propose the following rules for syntax:
 1. `pattern <Pat> :: <PatternType>`, when written outside of a `-boot`
 file, sets the first component of the type. It also sets the second
 component of the type when there is no separate type signature for `<Pat>`
 and when the pattern is declared to be bidirectional.

 2. `<Pat> :: Type` can be written to set the second component of a pattern
 synonym type.

 3. In a `-boot` file, a `pattern <Pat> :: <PatternType>` sets only the
 first component of a pattern synonym type. If you want a bidirectional
 pattern synonym, write two signatures.

 Note that point (2) creates something like a top-level signature (the kind
 we use all the time when defining functions) but for a capitalized (or
 `:`-prefixed) identifier. As far as I can tell, this is a new spot in the
 grammar (ignoring "naked" top-level declaration splices that consist of
 one identifier followed by a type annotation, which conflict with normal
 type signatures, anyway).

 What do we think? Please consider addressing design point (1) separately
 from design point (2), as I think that will simplify the discussion.

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