[GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932
GHC
ghc-devs at haskell.org
Mon Feb 29 17:23:43 UTC 2016
#11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932
-------------------------------------+-------------------------------------
Reporter: thomie | Owner: goldfire
Type: bug | Status: new
Priority: highest | Milestone: 8.0.1
Component: Compiler | Version: 8.1
Resolution: | Keywords: TypeInType
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):
I've been wondering if this dragon would bite. And now it has.
Consider
{{{
data T (a :: Proxy k)
}}}
Does that have a CUSK? According to the CUSK rules for datatypes, it does
indeed: all of the type variables have a kind signature. But there's a
problem in that we don't know `k`'s type! So this kind signature isn't
complete. Instead, we should need to say, e.g.,
{{{
data T :: forall (k :: *). Proxy k -> *
}}}
Note the explicit `:: *` on `k`'s binder, which is necessary for us to
have completely specify the kind.
However, in looking more closely at this case, I don't actually think this
is the problem. A mistake in detecting CUSKness should affect type
inference and whether or not we have principal kinds, etc., but it
shouldn't produce the drastic failure that we're seeing above. Somehow, it
seems that `quantifyTyVars` is making a mistake. I don't have the ability
to test this at the moment (I'm in an intermediate state) but should get
to this later this week. I propose to fix the immediate problem (which
should be straightforward) and then to delay the debate about CUSKs for
another time.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11648#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list