Simon Peyton Jones
| If the latter there is no reason to fear: TcBinds.addTypecheckedBinds | (which TcTypeable uses) ensures that no bindings are added to the | environment if we are compiling a boot module,
Ah, I had missed that; it's pretty deeply hidden.
Suggestion:
* Move tcRecSelBinds from tcAddImplicits, to mkTypeableBinds. More precisely, make a new function addDerivedBindings, which * add record-selector bindings (via tcRecSelBinds) * adds typeable bindings (via mkTypableBinds) and call it where we currently call mkTypeableBinds.
* Instead of burying the "drop the bindings" deep in addTypecheckedBinds, inline it into addDerivedBindings: - make mkTypeableBinds *return* bindings rather than extending gbl-env - ditto tcRecSelBinds Then addDerivedBinds can test hs-boot, and extend the tcg_binds if necessary
That would put the two together nicely, they really are very similar.
Lumping Typeable binding generation in with record selector generation is tricky... The problem is this: we must generate and typecheck record selectors on a per-group basis, since they may be used by later groups. However, to generate Typeable TyCon bindings we need to first generate a Module binding. However, we should only generate one Module binding per typechecked module, so this clearly can't be done per-group; moreover the Module binding can only be generated after types have been typechecked (since we may be generating bindings for GHC.Types, where Module itself is defined). The alternative here is to wire-in the Module and TyCon types, which I did previously but this lead to ticket:11120#comment:31. All of this is quite tiresome and I suspect things would be on the whole simpler if we just went back to wiring in these types, but that would require that we find a way to address comment:31. Of course, comment:31 itself would be moot if we could always rely on word64PrimTy being available, even on 64-bit architectures. I have long wondered why this isn't the case as it's a nasty inconsistency which adds a fair amount of ugliness in unexpected places (see, for instance, the definition of Word64 in GHC.Word). It seems to me like you should be able to use Word# if you just want a word-sized type and Word64# if you want a 64-bit type (regardless of the machine's word-size). Perhaps fixing this would and returning to wiring-in Module and TyCon be the easiest way forward. This would allow us to emit a Module binding at the beginning of typechecking and then emit TyCons in a per-group manner, just as we do for record selectors. Thoughts? Future plans aside,, would you be okay with pushing D2108 to the ghc-8.0 branch as-is in the interest of moving the release along? Cheers, - Ben