#11732: Deriving Generic1 interacts poorly with TypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType, | Generics 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): Yech. I'm beginning to believe that there is something wonky about the instantiation check. As it stands, the check forbids (or tries to) only visible parameters from being instantiated. But in the `TypeInType` world, there's not a rigid difference between visible parameters and invisible ones. It used to be that any parameter upon which another parameter depends (that is, a kind variable) must be invisible. That's not the case now. So doing a check like this based on visibility seems wrong. We could, potentially, do it based on dependency -- it's not so hard figure out which parameters are dependent. And indeed this information is readily available by looking at a `tyConBinders`: the `Named` ones are dependent, and the `Anon` ones are not. This should be as true for a data instance tycon as any other. So perhaps that's the way forward, and it explains why everything up to now has been just wrong: we were doing the wrong check. We were checking for visibility when we meant to check for dependency. So perhaps the check looks something like {{{ if (all isTyVarTy [ arg | (arg, binder) <- tc_args `zip` tyConBinders tc , isAnonBinder binder ]) ... }}} No more fussing with `filterOutInvisibleTypes` and no more bothering with `mkFamilyTyConApp`. Before blindly trying this, though, I'd love someone (Ryan, it seems) who understands Generics to consider what this instantiation check is really trying to do, and why it (previously) avoided looking at kinds. And why it makes sense to look at dependency, as I've proposed here. I've no real clue what's going on, and when I deleted `isKind` (which was what was used previously) I just reached for the closest thing, which was visibility. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11732#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler