Commit 8376027d authored by Jan Stolarek's avatar Jan Stolarek

Fix comment typos: lll -> ll, THe -> The

parent f0af3d85
......@@ -331,7 +331,7 @@ Notice (a) g has a different number of type variables to f, so we must
variables of the particular RHS. Tiresome.
Why got to this trouble? It's a common case, and it removes the
quadratic-sized tuple desugaring. Less clutter, hopefullly faster
quadratic-sized tuple desugaring. Less clutter, hopefully faster
compilation, especially in a case where there are a *lot* of
bindings.
......
......@@ -519,7 +519,7 @@ There is another wrinkle. With TH and -XDataKinds, consider
After splicing, but before renaming we get this:
data Nat_77{tc} = Zero_78{d}
data T_79{tc} = MkT_80{d} (Proxy 'Zero_78{tc}) |] )
THe occurrence of 'Zero in the data type for T has the right unique,
The occurrence of 'Zero in the data type for T has the right unique,
but it has a TcClsName name-space in its OccName. (This is set by
the ctxt_ns argument of Convert.thRdrName.) When we check that is
in scope in the GlobalRdrEnv, we need to look up the DataName namespace
......
......@@ -1728,7 +1728,7 @@ binder-swap in OccAnal:
Notice that because MkT is strict, x is marked "evaluated". But to
eliminate the last case, we must either make sure that x (as well as
x1) has unfolding MkT y1. THe straightforward thing to do is to do
x1) has unfolding MkT y1. The straightforward thing to do is to do
the binder-swap. So this whole note is a no-op.
It's fixed by doing the binder-swap in OccAnal because we can do the
......
......@@ -316,7 +316,7 @@ Nota bene:
2. It assumes that the binder type is lifted.
3. It does not check for pre-inline-unconditionallly;
3. It does not check for pre-inline-unconditionally;
that should have been done already.
\begin{code}
......
......@@ -1471,7 +1471,7 @@ So for the above example we generate:
$cop2 = <blah>
Note carefullly:
Note carefully:
* We *copy* any INLINE pragma from the default method $dmop1 to the
instance $cop1. Otherwise we'll just inline the former in the
......
......@@ -184,7 +184,7 @@ be a subset of the *quantified type variables* of the signatures, for two reason
* With kind polymorphism a signature like
f :: forall f a. f a -> f a
may actuallly give rise to
may actually give rise to
f :: forall k. forall (f::k -> *) (a:k). f a -> f a
So the sig_tvs will be [k,f,a], but only f,a are scoped.
NB: the scoped ones are not necessarily the *inital* ones!
......
......@@ -1000,7 +1000,7 @@ We can't require *equal* kinds, because
Note [Kind orientation for CFunEqCan]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For (F xis ~ rhs) we require that kind(lhs) is a subkind of kind(rhs).
This reallly only maters when rhs is an Open type variable (since only type
This really only maters when rhs is an Open type variable (since only type
variables have Open kinds):
F ty ~ (a:Open)
which can happen, say, from
......
......@@ -396,7 +396,7 @@ Type-family equations, of form (ev : F tys ~ ty), live in four places
* The inert_solved_funeqs. These are all "solved" goals (see Note [Solved constraints]),
the result of using a top-level type-family instance.
* THe inert_funeqs are un-solved but fully processed and in the InertCans.
* The inert_funeqs are un-solved but fully processed and in the InertCans.
\begin{code}
......
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