Tidy up TcTypeable
There is code in TcTypeable
that generates a KindRep
for each TyCon
(see Note [Representing TyCon kinds: KindRep]
). There's nothing actually wrong with it.
But it's pretty hard to understand. And it generates a staggering amount of data structure, when
compiling GHC.Types
.
Result size of Tidy Core
= {terms: 74,615, types: 41,335, coercions: 2, joins: 0/0}
Why? Well, it injects a TyCon
binding for each unboxed tuple size.
For example, here is the code for pairs (#,#)
$tc(#,#)
= TyCon 16533601304077481746##
7902994497850328874##
tr$ModuleGHCPrim
$tc(#,#)2
2#
$tc(#,#)1
-- TYPE #0 -> TYPE #1 -> TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))))
$tc(#,#)1 :: KindRep
$tc(#,#)1 = KindRepFun $krep2115_r6ji $krep18009_rarE
$krep18009_rarE = KindRepFun $krep2117_r6jk $krep18008_rarD
-- TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))))
$krep18008_rarD = KindRepTyConApp $tcTYPE $krep18007_rarC
$krep18007_rarC = : @ KindRep $krep18006_rarB ([] @ KindRep)
-- TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)))
$krep18006_rarB = KindRepTyConApp $tc'TupleRep $krep18005_rarA
$krep18005_rarA = : @ KindRep $krep2283_r6m0 ([] @ KindRep)
-- ': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))
$krep2283_r6m0 = KindRepTyConApp $tc': $krep2282_r6lZ
$krep2282_r6lZ = : @ KindRep $tc'AddrRep1 $krep2281_r6lY
$krep2281_r6lY = : @ KindRep $krep61_r5Ma $krep2280_r6lX
$krep2280_r6lX = : @ KindRep $krep2279_r6lW ([] @ KindRep)
-- ': RuntimeRep #1 ('[] RuntimeRep)
$krep2279_r6lW = KindRepTyConApp $tc': $krep2278_r6lV
$krep2278_r6lV = : @ KindRep $tc'AddrRep1 $krep2277_r6lU
$krep2277_r6lU = : @ KindRep $krep60_r5M9 $krep2276_r6lT
$krep2276_r6lT = : @ KindRep $krep2274_r6lR ([] @ KindRep)
-- '[] RuntimeRep
$krep2274_r6lR = KindRepTyConApp $tc'[] $krep2273_r6lQ
$krep2273_r6lQ = : @ KindRep $tc'AddrRep1 ([] @ KindRep)
-- RuntimeRep
$tc'AddrRep1 = KindRepTyConApp $tcRuntimeRep ([] @ KindRep)
-------------- TYPE #0
$krep2115_r6ji = KindRepTyConApp $tcTYPE $krep2114_r6jh
$krep2114_r6jh = : @ KindRep $krep61_r5Ma ([] @ KindRep)
$krep61_r5Ma = KindRepVar 0#
-------------- TYPE #1
$krep2117_r6jk = KindRepTyConApp $tcTYPE $krep2116_r6jj
$krep2116_r6jj = : @ KindRep $krep60_r5M9 ([] @ KindRep)
$krep60_r5M9 = KindRepVar 1#
That's a lot, and it's only for pairs. We generate all this up to 62-tuples!
Suggestions (read Note [Representing TyCon kinds: KindRep]
first)
-
KindRep
is a description of a polykind; an interpreter, calledinstantiateKindRep
turns it into a kind. So we can add whatever constructors we like toKindRep
. - One good one would be
UnboxedTupleRep n
, whichinstantiateKindRep
can instantiate to the kind of an unboxed tuple. It just moves the work somewhere else, of course, but it will make the generated code dramatically smaller. - We have a few canned kind-reps, via
TcTypeable.builtInKindReps
. It'd be simpler and easier instead to make each of them into a data constructor ofKindRep
. - Once that is done, I suspect that the entire machinery of tyring to share
KindReps
(which makes my head hurt) would be unnecessary
None of this is essential, but I think that matters can be improved.
Trac metadata
Trac field | Value |
---|---|
Version | 8.0.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |