Re: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context

5 Nov 2017

      #8581: Pattern synonym used in an expression context could have different
constraints to pattern used in a pattern context
-------------------------------------+-------------------------------------
        Reporter:  cactus            |                Owner:  (none)
            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 AntC):

 To heap a few more straws on this camel's back ...

 Pattern synonym used in an expression context could act as a smart
 constructor; and be used in a pattern context just for matching.

 {{{
 data Dumb = Dumb Int
 pattern {-# SMARTCONSTRUCTOR #-} Smart { nonneg } | nonneg >= 0 = Dumb
 nonneg

              -- or perhaps for better error messages
 pattern {-# SMARTCONSTRUCTOR #-} Smart { nonneg }  = assert (nonneg >= 0)
 $ Dumb nonneg
 }}}

 The downsides of a function-as-smart-constructor are:
 * You can only use the function in an expression context.
 * The function can't have named fields like a proper constructor.
 * The function can't be used for pattern match.
 * For pattern match, you can't allow the underlying data constructor to be
 in scope, for fear of abuse/breaking the type's invariant.
 * So you can't allow the underlying data constructor to appear in a
 pattern match, even though that would be safe.
 * Then you must define a unidirectional pattern synonym to support pattern
 match but not construction.
 * So now you've got an ugly set of module exports to provide the right
 name scoping: expose smart constructor function, pattern constructor and
 field labels; hide underlying constructor.

 Functions as smart constructors are not so smart, as a quick perusal of
 StackOverflow will show you.

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