[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 request    |                  Status:  new
       Priority:  normal             |               Milestone:
      Component:  Compiler           |                 Version:  7.8.3
       Keywords:                     |        Operating System:
   Architecture:  Unknown/Multiple   |  Unknown/Multiple
     Difficulty:  Unknown            |         Type of failure:
     Blocked By:                     |  None/Unknown
Related Tickets:                     |               Test Case:
                                     |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------
 Currently both PatternSynonyms and ConstraintKinds have to be enabled at
 the usage site, not just at the construction site.

 This pretty much ensures that they'll never be used to 'clean up' or
 virtualize an existing API, because switching to pattern synonyms for
 constructors or switching a 'class alias' to a type synonym immediately
 break all users.

 For instance right now, as a user I universally write

 {{{
 class (Foo a, Bar a) => Baz a
 instance (Foo a, Bar a) => Baz a
 }}}

 rather than

 {{{
 type Baz a = (Foo a, Bar a)
 }}}

 because the former gives a better user experience and I can pay all the
 extensions needed for it at the definition site, rather than have all my
 users pay them at the use site.

 I'd like to propose that the language extensions for these two cases,
 `PatternSynonyms` and `ConstraintKinds` only be required at the definition
 site, rather than at the use site.

 The former is definitely needed at the definition site because of the new
 syntax, but unless you explicitly re-export a pattern, no syntax changes
 at the usage site.

 This would also be more consistent with existing policies for other
 extensions:

 We don't require users to turn on FunctionalDependencies to get the
 benefit of functional dependencies, or to turn on MultiParamTypeClasses to
 use an MPTC, merely to define them.

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