[GHC] #11732: Deriving Generic1 interacts poorly with TypeInType

GHC ghc-devs at haskell.org
Sat Mar 26 20:56:21 UTC 2016


#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


More information about the ghc-tickets mailing list