Debug printing inside the typechecker knot
rae at richarde.dev
Thu Apr 4 19:05:19 UTC 2019
> 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
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.
> Ryan S.
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs