[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