#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