(Posted on behalf of Simon, who is on holiday.)
This patch implements the idea floated in Trac #9858, namely that we should
generate type-representation information at the data type declaration
site, rather than when solving a Typeable constraint.
However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
- Note [Grand plan for Typeable] in TcTypeable (which is a new module)
- Note [The overall promotion story] in DataCon (clarifies existing stuff)
The most painful bit was that to generate Typeable instances (ie TyConRepName
bindings) for every TyCon is tricky for types in ghc-prim etc:
- we need to have enough data types around to *define* a TyCon
- many of these types are wired-in
Also, to minimise the code generated for each data type, I wanted to generate
pure data, not CAFs with unpackCString# stuff floating about.
Three perf/compiler tests start to allocate quite a bit more. This isn't surprising,
because they all allocate zillions of data types, with practically no other code,
T1969: GHC allocates 30% more T5642: GHC allocates 14% more T9872d: GHC allocates 5% more
I'm treating this as acceptable. The payoff comes in Typeable-heavy code.
Remaining to do
- I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this
- Add more info the the "TyCon" e.g. source location where it was defined
- Use the new "Module" type to help with Trac Trac #10068
- It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult.
As is so often the case, I ended up refactoring more than I intended.
- In TyCon,
- a type *family* (whether type or data) is repesented by a FamilyTyCon
- a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn.
Also get rid of the (unhelpfully named) tyConParent.
- In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC.
- Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance.
- I added PatSynId, DefMethId, and ReflectionId to the IdInfo.IdDetails type. They are used for debugging only, namely to suppress excessive output in -ddump-types.
- Tidy up the generation of PrelInfo.knownKeyNames
- Move newImplicitBinder from IfaceEnv to BuildTyCl
- PrelNames.conName renamed to dcQual for consistency with varQual, tcQual
- Move mkDefaultMethodIds, mkRecSelBinds from TcTyClsDecls to TcTyDecls