#14331: Overzealous free-floating kind check causes deriving clause to be rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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 goldfire): I'm taking a look at your work, but it would be much more ergonomic to review this in Phab. Rough comments: - Why the `newMetaTyVars` at the top? That doesn't look right to me. - You're trying to swap the `tcUnifyTy` with a `unifyType`. Good. But the `tcUnifyTy` is still there. Is this intentional or an aspect of the fact that this is w.i.p.? - Before you call `unifyType`, you need to have metavariables that `unifyType` will unify. According to comment:31, these variables should be as specified in step (h) of the algorithm. So perhaps you do need `newMetaTyVars`, but not over all the tvs, just a subset of them. - The second half of step (i) of the algorithm (skolemizing unbound metavariables) might nicely be accomplished by `quantifyTyVars`. It's a bit unclear to me without thinking more about this whether this function does too much, but its helper function `zonkQuantifiedTyVar` is definitely what you need to do. I hope this gets you going again... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14331#comment:48 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler