[GHC] #14332: Deriving clauses can have forall types

[GHC]

#14332: Deriving clauses can have forall types
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  8.2.1
  checker)                           |
      Resolution:                    |             Keywords:  deriving
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC accepts       |  Unknown/Multiple
  invalid program                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Replying to [comment:9 goldfire]:
 > In both of your examples, IIUC, the unification happens to the datatype
 variables, not the newly-quantified variables in the `deriving` clause. I
 agree that this kind unification is good. I further agree that any
 unwritten kinds in a `deriving` clause should be unified.

 I am baffled as to why we are drawing these arbitrary distinctions among
 slightly different positionings of kind variables in a data declaration. I
 want to believe that there is some overarching principle behind these
 viewpoints, but it's either not spelled out anywhere, or I'm too dense to
 discern it from the subtext (or both).

 > But I think any explicitly written kinds are skolems, and that this
 doesn't cause problems.

 OK. But in `data Proxy (a :: k) = Proxy deriving Functor`, `k` is //also//
 a user-written kind! Why should this not be considered rigid, but the `k`
 in `data D = D deriving (C k)` should be considered rigid?

 I swear I'm not trying to be contrarian here simply to be stubborn. But
 from my viewpoint, all of these proposed changes are adding a ton of
 complexity, and moreover, they are ruling out classes of programs that
 currently typecheck. I don't think it's healthy to view the `C c1 ... cn`
 in `deriving (C1 ... cn)` like the types in other class instance heads,
 because `C c1 ... cn` isn't like other types—it's a macro, not a
 standalone thing. We shouldn't foist our biases of other types onto this
 construct, which is quite different from anything else in Haskell.

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