[GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected

[GHC]

#14331: Overzealous free-floating kind check causes deriving clause to be rejected
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  merge
        Priority:  normal            |            Milestone:  8.2.2
       Component:  Compiler (Type    |              Version:  8.2.1
  checker)                           |
      Resolution:                    |             Keywords:  deriving
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  deriving/should_compile/T14331
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Replying to [comment:37 simonpj]:
 > It seems absurdly ad-hoc.

 I'm not sure what makes this any more //ad hoc// than anything else we do
 to derive `Functor`.

 I'd caution against letting the tail wag the dog here—if something in our
 algorithm rules out a fundamentally important case like deriving `Functor`
 for `Compose`, then I'd interpret that as meaning our algorithm is wrong,
 not the example.

 > 1. Require standalone deriving in such cases.  It's not so bad, and is a
 lot clearer!  I'm against inferring too much.  Indeed I'd happily weaken
 our existing inference further.  (Acknowledging back-compat issues.)

 I'm strongly opposed to this. There's no intuitive reason why `deriving
 Functor` shouldn't just work in this case, and now we'd have to explain to
 a mob of pitchfork-wielding Haskell users why their code broke due to GHC
 not "inferring too much".

 > 2. Do it properly.  That is, after simplifying the instance constraints
 we'll end up with`k~Type` in these cases, and perhaps others.  Instead of
 rejecting such constraints as too exotic, simply commit to them.  That's
 the "extra unification".

 For obvious reasons, I'd prefer this option to option 1. But I'll admit
 that I don't understand the proposed fix here. At what point does instance
 constraint simplification derive a `k ~ Type` constraint?

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