#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#L... gets partially applied in https://github.com/ekmett/hask/blob/master/src/Hask/Category/Polynomial.hs#L... etc. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9838#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler