[GHC] #15591: Inconsistent kind variable binder visibility between associated and non-associated type families

[GHC]

#15591: Inconsistent kind variable binder visibility between associated and non-
associated type families
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.5
      Resolution:                    |             Keywords:
                                     |  TypeApplications, TypeFamilies
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 goldfire):

 For comment:4's `C`, I would expect

 {{{
 C :: Type -> Constraint   -- a is required, but it's not mentioned by name
 in the kind
 T2 :: forall (a :: Type) (f :: Type -> Type). f a -> Type
 }}}

 In `T2`'s kind, I've put `a` first, because it was already in scope. This
 parallels the fact that class variables are quantified before other
 variables in polymorphic methods. Both `a` and `f` should be `Specified`,
 as they are user-written. The various `Type`s in the kind of `T2` arise
 from the defaulting behavior of open type families (unchanged in this
 conversation).

 The specification of `Specified`/`Inferred` is very simple: if the user
 has written the variable name in the declaration, the variable is
 `Specified`. If not, it's `Inferred`.

 As for the patch: I would expect that the solution to this problem would
 be in the type-checker, not the renamer. As it stands, I'm pretty sure
 that the renamer identifies the `a` in these associated type definitions
 with the same unique as the `a` in the class.

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