Commit 1f924cb3 authored by Sasa Bogicevic's avatar Sasa Bogicevic 💬 Committed by Krzysztof Gogolewski

Correct spelling errors

Reviewers: bgamari, osa1

Reviewed By: osa1

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15408

Differential Revision: https://phabricator.haskell.org/D4978
parent 2c38a6ee
......@@ -558,7 +558,7 @@ tcSubTypeET _ _ (Infer inf_res) ty_expected
= ASSERT2( not (ir_inst inf_res), ppr inf_res $$ ppr ty_expected )
-- An (Infer inf_res) ExpSigmaType passed into tcSubTypeET never
-- has the ir_inst field set. Reason: in patterns (which is what
-- tcSubTypeET is used for) do not agressively instantiate
-- tcSubTypeET is used for) do not aggressively instantiate
do { co <- fill_infer_result ty_expected inf_res
-- Since ir_inst is false, we can skip fillInferResult
-- and go straight to fill_infer_result
......@@ -750,7 +750,7 @@ tc_sub_type_ds eq_orig inst_orig ctxt ty_actual ty_expected
-- go ty_a (TyVarTy alpha)
-- which, in the impredicative case unified alpha := ty_a
-- where th_a is a polytype. Not only is this probably bogus (we
-- simply do not have decent story for imprdicative types), but it
-- simply do not have decent story for impredicative types), but it
-- caused Trac #12616 because (also bizarrely) 'deriving' code had
-- -XImpredicativeTypes on. I deleted the entire case.
......@@ -907,7 +907,7 @@ has the ir_inst flag.
f :: forall {a}. a -> forall b. Num b => b -> b -> b
This is surely confusing for users.
And worse, the monomorphism restriction won't properly. The MR is
And worse, the monomorphism restriction won't work properly. The MR is
dealt with in simplifyInfer, and simplifyInfer has no way of
instantiating. This could perhaps be worked around, but it may be
hard to know even when instantiation should happen.
......@@ -1024,7 +1024,7 @@ to
(forall a. a->a) -> alpha[l+1]
and emit the constraint
[W] alpha[l+1] ~ Int
Now the poromoted type can fill the ref cell, while the emitted
Now the promoted type can fill the ref cell, while the emitted
equality can float or not, according to the usual rules.
But that's not quite right! We are exposing the arrow! We could
......@@ -1037,7 +1037,7 @@ Here we abstract over the '->' inside the forall, in case that
is subject to an equality constraint from a GADT match.
Note that we kept the outer (->) because that's part of
the polymorphic "shape". And becauuse of impredicativity,
the polymorphic "shape". And because of impredicativity,
GADT matches can't give equalities that affect polymorphic
shape.
......@@ -1662,7 +1662,7 @@ So we look for a positive reason to swap, using a three-step test:
on the left because there are fewer
restrictions on updating TauTvs
- SigTv/TauTv: put on the left eitehr
- SigTv/TauTv: put on the left either
a) Because it's touchable and can be unified, or
b) Even if it's not touchable, TcSimplify.floatEqualities
looks for meta tyvars on the left
......@@ -1694,7 +1694,7 @@ Wanteds and Givens, but either way, deepest wins! Simple.
If we orient the Given a[2] on the left, we'll rewrite the Wanted to
(beta[1] ~ b[1]), and that can float out of the implication.
Otherwise it can't. By putting the deepest variable on the left
we maximise our changes of elminating skolem capture.
we maximise our changes of eliminating skolem capture.
See also TcSMonad Note [Let-bound skolems] for another reason
to orient with the deepest skolem on the left.
......@@ -1757,7 +1757,7 @@ where fsk is a flatten-skolem (FlatSkolTv). Suppose we have
then we'll reduce the second constraint to
[G] a ~ fsk
and then replace all uses of 'a' with fsk. That's bad because
in error messages intead of saying 'a' we'll say (F [a]). In all
in error messages instead of saying 'a' we'll say (F [a]). In all
places, including those where the programmer wrote 'a' in the first
place. Very confusing! See Trac #7862.
......@@ -1997,7 +1997,7 @@ matchExpectedFunKind hs_ty = go
Suppose we are considering unifying
(alpha :: *) ~ Int -> (beta :: alpha -> alpha)
This may be an error (what is that alpha doing inside beta's kind?),
but we must not make the mistake of actuallyy unifying or we'll
but we must not make the mistake of actually unifying or we'll
build an infinite data structure. So when looking for occurrences
of alpha in the rhs, we must look in the kinds of type variables
that occur there.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment