#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