From 3c9dc06ba2034e867c9169e60e854539875654fd Mon Sep 17 00:00:00 2001 From: Brian Wignall Date: Thu, 19 Dec 2019 09:11:42 -0500 Subject: Fix typos, via a Levenshtein-style corrector --- compiler/types/Coercion.hs | 2 +- compiler/types/OptCoercion.hs | 2 +- compiler/types/TyCoFVs.hs | 2 +- compiler/types/TyCoSubst.hs | 2 +- compiler/types/TyCoTidy.hs | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) (limited to 'compiler/types') diff --git a/compiler/types/Coercion.hs b/compiler/types/Coercion.hs index b338bfbf9e..16db7c5f6c 100644 --- a/compiler/types/Coercion.hs +++ b/compiler/types/Coercion.hs @@ -1943,7 +1943,7 @@ liftCoSubstTyVar (LC subst env) r v callback: We want 'liftCoSubstVarBndrUsing' to be general enough to be reused in - FamInstEnv, therefore the input arg 'fun' returns a pair with polymophic type + FamInstEnv, therefore the input arg 'fun' returns a pair with polymorphic type in snd. However in 'liftCoSubstVarBndr', we don't need the snd, so we use unit and ignore the fourth component of the return value. diff --git a/compiler/types/OptCoercion.hs b/compiler/types/OptCoercion.hs index 55771f6dd0..b8f9f6ce8f 100644 --- a/compiler/types/OptCoercion.hs +++ b/compiler/types/OptCoercion.hs @@ -1166,7 +1166,7 @@ etaTyConAppCo_maybe tc co , tc1 == tc2 , isInjectiveTyCon tc r -- See Note [NthCo and newtypes] in TyCoRep , let n = length tys1 - , tys2 `lengthIs` n -- This can fail in an erroneous progam + , tys2 `lengthIs` n -- This can fail in an erroneous program -- E.g. T a ~# T a b -- #14607 = ASSERT( tc == tc1 ) diff --git a/compiler/types/TyCoFVs.hs b/compiler/types/TyCoFVs.hs index eefd68f145..10dc6453b0 100644 --- a/compiler/types/TyCoFVs.hs +++ b/compiler/types/TyCoFVs.hs @@ -84,7 +84,7 @@ so we profiled several versions, exploring different implementation strategies. This looks deceptively similar, but while FV internally builds a list- and set-generating function, the VarSet functions manipulate sets directly, and - the latter peforms a lot worse than the naive FV version. + the latter performs a lot worse than the naive FV version. 3. Accumulator-style VarSet version: this is what we use now. We do use VarSet as our data structure, but delegate the actual work to a new diff --git a/compiler/types/TyCoSubst.hs b/compiler/types/TyCoSubst.hs index db7563914f..7c1a811ae3 100644 --- a/compiler/types/TyCoSubst.hs +++ b/compiler/types/TyCoSubst.hs @@ -527,7 +527,7 @@ hole will remain. Then, when we're checking x's definition, we skolemise x's type (in order to, e.g., bring the scoped type variable `a` into scope). This requires performing a substitution for the fresh skolem variables. -This subsitution needs to affect the kind of the coercion hole, too -- +This substitution needs to affect the kind of the coercion hole, too -- otherwise, the kind will have an out-of-scope variable in it. More problematically in practice (we won't actually notice the out-of-scope variable ever), skolems in the kind might have too high a level, triggering a failure to uphold the diff --git a/compiler/types/TyCoTidy.hs b/compiler/types/TyCoTidy.hs index 5c0825a6fa..f4639ca303 100644 --- a/compiler/types/TyCoTidy.hs +++ b/compiler/types/TyCoTidy.hs @@ -144,7 +144,7 @@ tidyType env (CoercionTy co) = CoercionTy $! (tidyCo env co) -- The following two functions differ from mkForAllTys and splitForAllTys in that --- they expect/preserve the ArgFlag argument. Thes belong to types/Type.hs, but +-- they expect/preserve the ArgFlag argument. These belong to types/Type.hs, but -- how should they be named? mkForAllTys' :: [(TyCoVar, ArgFlag)] -> Type -> Type mkForAllTys' tvvs ty = foldr strictMkForAllTy ty tvvs -- cgit v1.2.1