Iavor, Richard, and others
We always thought it was the Right Thing to generate the runtime representation for a TyCon (used in Typeable type representations) at the definition site of the type, not "on the fly". I thought I'd do this.
But it was a LOT harder than I expected. I have spent a ridiculous amount of time on it over the last three weeks. Sigh.
However (a) it's done, (b) I did a lot of other tidying up (as usual). So I'm keen to use it.
Would you like to take a look? It's on branch wip/T9858-typeable-spj. Relevant log messages below.
Unsurprisingly, some perf/compiler tests get a bit slower (see below).
More surprisingly, there are two perf/should_run tests that get worse
perf/should_run T5205 [stat not good enough] (normal)
perf/should_run lazy-bs-alloc [stat not good enough] (normal)
This is much more surprising: neither seems to have anything much to do with Typeable. But I can't investigate before I go on holiday. Would anyone else like to?
It's all up to date wrt HEAD.
Simon
commit fcd18c42b6ae2e73a9f4c67dbe6d994b0f8468c8
Author: Simon Peyton Jones <simonpj(a)microsoft.com>
Date: Thu Mar 26 11:06:12 2015 +0000
Remove a redndant 'return'
commit a6200759fd2f3f0e901cb2092e148bf31abb08b4
Author: Simon Peyton Jones <simonpj(a)microsoft.com>
Date: Mon Mar 23 14:53:53 2015 +0000
Error message wibbles
These are associated with
- new instance reporting
- typeable changes in -ddump-simpl output
- -ddump-types being a bit less verbose
- some renaming of type variables in debugger output (no idea why this happens)
commit fe510d911b6cf61d6884b8b42d8771d4aea3229f
Author: Simon Peyton Jones <simonpj(a)microsoft.com>
Date: Mon Mar 23 14:50:23 2015 +0000
Generate Typeble info at definition sites
This patch implements the idea floated in #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
a struggle.
See particularly
* 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.
Performance
~~~~~~~~~~~
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,
esp T1969
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 #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.
Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular
* 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
commit 021e6f583a1159b0a3581ab1713d560cadc2bdf7
Author: Simon Peyton Jones <simonpj(a)microsoft.com>
Date: Mon Mar 23 14:32:31 2015 +0000
tcRnDeclsi can use tcRnSrcDecls
I'm not sure why tcRnDeclsi didn't call tcRnSrcDecls before, but now it
does. About 20 lines of code vanish. Hooray.
commit 6473d110ab1aa22a5933e405b59e3f597562ce02
Author: Simon Peyton Jones <simonpj(a)microsoft.com>
Date: Fri Mar 20 12:38:42 2015 +0000
Implement lookupGlobal in TcEnv, and use it
This localises the (revolting) initTcForLookup function, exposing
instead the more civilised interface for lookupGlobal
commit 7078a11f50e3af9139dd5ceef032e89047677833
Author: Simon Peyton Jones <simonpj(a)microsoft.com>
Date: Fri Mar 20 12:36:22 2015 +0000
Comments and white space
commit 48512df5751a07fd503f0ba523e5504d09ee258d
Author: Simon Peyton Jones <simonpj(a)microsoft.com>
Date: Fri Mar 20 12:27:59 2015 +0000
Improve the error messages for class instance errors
See Note [Displaying potential instances].
simonpj@cam-05-unx:~/code/HEAD-5$
