> On Apr 4, 2019, at 2:55 PM, Ryan Scott <[email protected]> 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 > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
