
#12001: RFC: Add pattern synonyms to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: 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 Iceland_jack): Great responses, there are obviously no best practices yet for this extension. As the dust settles, will we only accept ''constructor-like'' patterns? Are non-constructor-like patterns wholly undesirable or are there examples where they are worth it? I personally use all of these to good effect, let's wait until we understand them better. Let's identify and categorise some of these examples: === Literal synonyms === Bidirectional patterns, nothing fancy {{{#!hs pattern I a = Identity a pattern K a = Const a pattern Less = LT }}} === ‘Getter’ patterns === Unidirectional patterns, these are essentially ‘Getter’s {{{#!hs pattern Real r <- r :+ _ pattern Imaginary i <- _ :+ i }}} === Constructor-Like Patterns === (Implicitly) bidirectional patterns that don't lose information {{{#!hs pattern Real, Imaginary :: (Num a, Eq a) => a -> Complex pattern Real r = r :+ 0 (Implicitly) pattern Imaginary i = 0 :+ i }}} In this case this is the identity function on complex numbers: {{{#!hs f :: (Num a, Eq a) => Complex a -> Complex a f (Real r) = Real r f complex = complex }}} @ekmett argues for this property [https://github.com/ekmett/lens/issues/653 here]. === Non-Constructor-Like Patterns === Explicitly bidirectional patterns that do lose information {{{#!hs pattern Real, Imaginary :: Num a => a -> Complex a pattern Real r <- r :+ _ where Real r = r :+ 0 pattern Imaginary i <- _ :+ i where Imaginary i = 0 :+ i }}} We lose the constructor property, but matching never fails so it's closer to the lens `_realPart`. ---- We can keep this ticket open until the extension and understanding matures, same as #11349 where [https://github.com/RyanGlScott/proxied/blob/master/src/Data/Proxyless.hs Data.Proxyless] was created in response. It has been said of me that I embrace pattern synonyms to “almost an absurd level” so someone needs to show restraint `:--)` tickets such as #11977 show that this extension still isn't even fully understood and I look forward to seeing how it evolves -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12001#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler