Debug printing inside the typechecker knot

Richard Eisenberg rae at
Thu Apr 4 18:38:09 UTC 2019

Though a ZonkEnv does some important work when zonking *terms*, it's just an optimization when zonking *types*.

You want TcMType.zonkTcType.

I hope this helps!

> On Apr 4, 2019, at 10:38 AM, Ryan Scott < at> wrote:
> I've recently found myself wanting to add some pprTrace statements in
> typechecker-related code but unable to do so, as the code would pull
> on knot-tied TyCons (leading to an infinite loop if actually ran). In
> particular, I want to print some code [1] in TcTyClsDecls.tcConDecl:
>       ; (ze, tkvs)     <- zonkTyBndrs tkvs
>       ; (ze, user_tvs) <- zonkTyBndrsX ze user_tvs
>       ; arg_tys <- zonkTcTypesToTypesX ze arg_tys
>       ; ctxt    <- zonkTcTypesToTypesX ze ctxt
>       ; res_ty  <- zonkTcTypeToTypeX   ze res_ty
>       ; let (univ_tvs, ex_tvs, tkvs', user_tvs', eq_preds, arg_subst)
>               = rejigConRes tmpl_bndrs res_tmpl tkvs user_tvs res_ty
> In [2], goldfire claimed that there is a way to work around this problem now:
>> But you can do this. It just has to be before the final zonk. I
> see that rejigConRes is used after the final zonk. But there's nothing
> about that function that requires things be in their final state. The
> arguments need to be zonked, but they can be zonked by zonkTcType and
> friends, not zonkTcTypeToType and friends. So, for debugging: zonk
> everything with the functions in TcMType (not those in TcHsSyn). Then
> rejigConRes. Then print all the output you like. Then do the final
> zonk. This double-zonk is redundant, so it's not good to keep going
> forward, but it shouldn't cause other trouble.
> Unfortunately, this advice doesn't seem to pan out in practice. I
> started off by looking for a TcMType equivalent of this function:
>    zonkTcTypeToTypeX :: ZonkEnv -> TcType -> TcM Type
> However, I am utterly unable to find anything defined in TcMType with
> a similar type signature. Actually, it's worse than that: there isn't
> a single mention of ZonkEnv anywhere in TcMType! So as far as I can
> tell, this advice is completely unimplementable, unless I'm missing
> something obvious. Any tips?
> Ryan S.
> -----
> [1]
> [2]
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

More information about the ghc-devs mailing list