[GHC] #11824: GHC error in desugarer lookup

[Ben Gamari]

Simon Peyton Jones <simonpj at microsoft.com> writes:

> |  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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160416/a0b50cca/attachment.sig>