#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