Debug printing inside the typechecker knot

[Richard Eisenberg]

> On Apr 4, 2019, at 2:55 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
> 
> Good to know, thanks. I assume that TcMType.zonkTcTypes is to
> TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to
> TcHsType.zonkTyBndrs?

No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs returns a [TyVar] -- this won't end well. If you look further in zonkTyBndrs, you'll see that it calls `zonkTcTypeToType (tyVarKind tv)` (roughly), making the equivalent to be TcMType.zonkTyCoVarKind.

Clearly, it would behoove use to rename these functions to be more systematic.

> 
> Also, what exactly is the optimization that ZonkEnv performs in types?
> And why don't the functions in TcMType make use of this optimization?

Suppose we have

forall (a :: kappa). ... a ...

We laboriously discover that kappa should be (Type -> Type). The ZonkEnv stores a mapping (a |-> (a :: Type -> Type)) so that when we spot the `a` in the body of the forall, we don't have to repeat the zonk -- we just do a lookup. But, of course, zonking the occurrence of `a` would also work.

Why don't we do this in TcMType? There's likely no good reason -- it would be effective there, too. But it would be less effective. The code in TcHsSyn generally starts with *closed* types/terms, meaning that all type variables will be brought into scope somewhere. In contrast, TcMType functions can work over *open* terms, so we have less opportunity to extend the ZonkEnv.

Richard

> 
> Ryan S.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs