#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 dfeuer): Replying to [comment:45 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.
I like the general theme very much, but I think we use the `constructor` keyword to introduce capitalized identifiers as well as to export them unbundled. This distinguishes them syntactically from pattern bindings and makes it immediately obvious that something strange is happening. I agree that we don't need to allow them to be defined using pattern bindings; that would complicate things with little benefit. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8581#comment:46 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler