Let's not think about implementation before we have a ''design''. I have not read the entire thread again, but I'm pretty convinced that
* We can't have two different types, one for construction and one for
#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:34 simonpj]: pattern matching
I think it'll just be too confusing to have two types. It's bad enough
to have this provided/required stuff without, in addition, having a completely separate type for construction. Are you seriously proposing to have two signatures for each pattern synonym? (Optionally, I assume.) I respectfully disagree. Pattern synonyms are not, and likely will never be, written by many beginners. And very few programmers are likely to need to write terribly many of them. I think, therefore, that making the type checker enforce some sort of "reasonableness" on them is a considerably lower priority than making them powerful enough to do what librarians need them to do. I ran into this yesterday writing a pattern synonym for Edward Yang's `NF` type (in the `nf` package), which needs a constraint on construction but not on matching. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8581#comment:37 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler