[GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site.

[GHC]

#9838: PatternSynonyms and ConstraintKinds should not be required at the use site.
-------------------------------------+-------------------------------------
              Reporter:  ekmett      |            Owner:
                  Type:  feature     |           Status:  new
  request                            |        Milestone:
              Priority:  normal      |          Version:  7.8.3
             Component:  Compiler    |         Keywords:
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:              |  Related Tickets:
  None/Unknown                       |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by ekmett):

 Re: `ConstraintKinds`

 You can construct a fairly simple example where someone wants to have
 something that they can put in a context that, say, offered both
 `Applicative m` and `Monad m` as a stopgap for the AMP.

 {{{
 class (Applicative m, Monad m) => ApplicativeMonad m
 instance (Applicative m, Monad m) => ApplicativeMonad m
 }}}

 as opposed to

 {{{
 type ApplicativeMonad m = (Applicative m, Monad m)
 }}}

 Similar hack-arounds are common among folks who see `Semigroup` as a
 superclass of `Monoid`, but who have to workaround the lack of a
 superclass relationship.

 These sorts of synonyms are actually quite common, I think I first used it
 back around 2006 when I first found haskell: e.g. TXOr in
 http://hackage.haskell.org/package/type-int-0.5.0.2/docs/src/Data-Type-
 Boolean.html#TXOr is an instance of this pattern, but it was a well known
 pattern long before the time I started using it.

 The former requires "scarier" extensions than the latter for the person
 constructing it, but the latter requires an extension to be turned on by
 the user, hoisting the library designer upon the horns of a dilemma, do
 they take the burden upon themselves and use "the old way" of thinking
 about these things or do they make every user turn on `ConstraintKinds`?

 Mind you it still isn't a clean decision even with this change, because
 the former still works better in some scenarios, e.g. you can pass the
 class/instance version of `ApplicativeMonad` as an argument that expects
 something of kind `(* -> *) -> Constraint`, but the type synonym version
 cannot be partially applied, but these are the kinds of thoughts users of
 `ConstraintKinds` wind up thinking.

 Almost all of my current real world examples of this are now entangled
 with this secondary concern:

 e.g.

 https://github.com/ekmett/hask/blob/master/src/Hask/Category.hs#L93 gets
 partially applied in
 https://github.com/ekmett/hask/blob/master/src/Hask/Category.hs#L283

 https://github.com/ekmett/hask/blob/master/src/Hask/Category/Polynomial.hs#L35
 gets partially applied in
 https://github.com/ekmett/hask/blob/master/src/Hask/Category/Polynomial.hs#L50

 etc.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9838#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler