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

 The idea in comment:39 has grown on me. So let me turn this into a
 concrete proposal:

 1. Relax Haskell's current restriction around capitalized identifiers.
 That is, any old variable can now begin with a capitalized letter or a
 colon. Capitalized variables can be defined only by function-definition
 syntax, never by patterns. That is, `Foo = 5` is OK, as is `Bar x = x +
 2`. On the other hand, `Just Quux = listToMaybe blurgh` would not be OK.

 2. Unidirectional pattern synonyms remain unchanged.

 3. If a bidirectional (whether implicitly bidirectional or explicitly
 bidirectional) pattern synonym is defined in a module, and that module
 defines no variable of the same (capitalized) name as the pattern, then
 the pattern synonym declaration also serves as a declaration of the
 capitalized identifier. The type of the capitalized identifier will be
 derived from the type of the pattern synonym, concatenating the required
 and provided contexts.

 4. A pattern synonym signature in a `-boot` file declares only the pattern
 synonym, not the capitalized identifier.

 5. Export and import of capitalized identifiers will need a new keyword
 prefix in export/import lists. I propose `constructor`, analogous to
 `pattern` today.

 6. Exporting/importing a pattern synonym with an implicitly-declared
 capitalized identifier associated with it will also export/import that
 capitalized identifier. This is mostly for backward compatibility, but it
 also seems quite convenient.

 What do we think? Some of this design is motivated by backward
 compatibility with existing pattern synonyms -- we could imagine having
 pattern synonyms always be unidirectional and asking users to declare both
 ways explicitly. But this is also inconvenient for the common case. I
 think this proposal balances the different needs nicely. It also suggests
 that we can do away entirely with "builders" in the implementation, as a
 capitalized identifier is just a normal variable.

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