Commit bbf36f89 authored by Gabor Greif's avatar Gabor Greif 💬

More typos in comments

parent e710f8f5
......@@ -672,7 +672,7 @@ We want the user to express a rule saying roughly “mapping a coercion over a
list can be replaced by a coercion”. But the cast operator of Core (▷) cannot
be written in Haskell. So we use `coerce` for that (#2110). The user writes
map coerce = coerce
as a RULE, and this optimizes any kind of mapped' casts aways, including `map
as a RULE, and this optimizes any kind of mapped' casts away, including `map
MkNewtype`.
For that we replace any forall'ed `c :: Coercible a b` value in a RULE by
......
......@@ -133,7 +133,7 @@ isTrueLHsExpr :: LHsExpr Id -> Maybe (CoreExpr -> DsM CoreExpr)
-- * 'otherwise' Id
-- * Trivial wappings of these
-- The arguments to Just are any HsTicks that we have found,
-- because we still want to tick then, even it they are aways evaluted.
-- because we still want to tick then, even it they are always evaluated.
isTrueLHsExpr (L _ (HsVar (L _ v))) | v `hasKey` otherwiseIdKey
|| v `hasKey` getUnique trueDataConId
= Just return
......
......@@ -2527,7 +2527,7 @@ primop ParOp "par#" GenPrimOp
a -> Int#
with
-- Note that Par is lazy to avoid that the sparked thing
-- gets evaluted strictly, which it should *not* be
-- gets evaluated strictly, which it should *not* be
has_side_effects = True
code_size = { primOpCodeSizeForeignCall }
......
......@@ -150,7 +150,7 @@ The interesting cases of the analysis:
Only one can be execuded, so
Return (alt₁ ∪ alt₂ ∪...)
* App e₁ e₂ (and analogously Case scrut alts), with non-trivial e₂:
We get the results from both sides, with the argument evaluted at most once.
We get the results from both sides, with the argument evaluated at most once.
Additionally, anything called by e₁ can possibly be called with anything
from e₂.
Return: C(e₁) ∪ C(e₂) ∪ (fv e₁) × (fv e₂)
......
......@@ -2307,12 +2307,12 @@ is used:
Now give it to the simplifier and the _Lifting will be optimised away.
The benfit is that we have given the specialised "unboxed" values a
very simplep lifted semantics and then leave it up to the simplifier to
The benefit is that we have given the specialised "unboxed" values a
very simple lifted semantics and then leave it up to the simplifier to
optimise it --- knowing that the overheads will be removed in nearly
all cases.
In particular, the value will only be evaluted in the branches of the
In particular, the value will only be evaluated in the branches of the
program which use it, rather than being forced at the point where the
value is bound. For example:
......
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