Another batch of typo fixes in non-code

10 files changed, 10 insertions, 10 deletions

diff --git a/compiler/basicTypes/Demand.hs b/compiler/basicTypes/Demand.hs
index 2fd9981c1b..96e02b2a23 100644
--- a/compiler/basicTypes/Demand.hs
+++ b/compiler/basicTypes/Demand.hs
@@ -1333,7 +1333,7 @@ strictenDmd (JD { sd = s, ud = u})
     poke_u Abs       = UHead
     poke_u (Use _ u) = u
 
--- Deferring and peeeling
+-- Deferring and peeling
 
 type DmdShell   -- Describes the "outer shell"
                 -- of a Demand
diff --git a/compiler/codeGen/StgCmmClosure.hs b/compiler/codeGen/StgCmmClosure.hs
index dca026dccd..9b1545f2db 100644
--- a/compiler/codeGen/StgCmmClosure.hs
+++ b/compiler/codeGen/StgCmmClosure.hs
@@ -438,7 +438,7 @@ floated them out.  Well, a clever optimiser might leave one there to
 avoid a space leak, deliberately recomputing a thunk.  Also (and this
 really does happen occasionally) let-floating may make a function f smaller
 so it can be inlined, so now (f True) may generate a local no-fv closure.
-This actually happened during bootsrapping GHC itself, with f=mkRdrFunBind
+This actually happened during bootstrapping GHC itself, with f=mkRdrFunBind
 in TcGenDeriv.) -}
 
 -----------------------------------------------------------------------------
diff --git a/compiler/deSugar/DsUtils.hs b/compiler/deSugar/DsUtils.hs
index b96b3eb59b..f47c847756 100644
--- a/compiler/deSugar/DsUtils.hs
+++ b/compiler/deSugar/DsUtils.hs
@@ -554,7 +554,7 @@ mkCoreAppsDs :: SDoc -> CoreExpr -> [CoreExpr] -> CoreExpr
 mkCoreAppsDs s fun args = foldl (mkCoreAppDs s) fun args
 
 mkCastDs :: CoreExpr -> Coercion -> CoreExpr
--- We define a desugarer-specific verison of CoreUtils.mkCast,
+-- We define a desugarer-specific version of CoreUtils.mkCast,
 -- because in the immediate output of the desugarer, we can have
 -- apparently-mis-matched coercions:  E.g.
 --     let a = b
diff --git a/compiler/main/TidyPgm.hs b/compiler/main/TidyPgm.hs
index 63f4c2665f..df31fda16c 100644
--- a/compiler/main/TidyPgm.hs
+++ b/compiler/main/TidyPgm.hs
@@ -891,7 +891,7 @@ codegen time.  I found that binary sizes jumped by 6-10% when I
 started to specialise INLINE functions (again, Note [Inline
 specialisations] in Specialise).
 
-So it seeems better to drop the binding for f_spec, and the rule
+So it seems better to drop the binding for f_spec, and the rule
 itself, if the auto-generated rule is the *only* reason that it is
 being kept alive.
 
diff --git a/compiler/prelude/TysWiredIn.hs b/compiler/prelude/TysWiredIn.hs
index cb9438a1ad..6ad786fd0f 100644
--- a/compiler/prelude/TysWiredIn.hs
+++ b/compiler/prelude/TysWiredIn.hs
@@ -446,7 +446,7 @@ Note [How tuples work]  See also Note [Known-key names] in PrelNames
 * When looking up an OccName in the original-name cache
   (IfaceEnv.lookupOrigNameCache), we spot the tuple OccName to make sure
   we get the right wired-in name.  This guy can't tell the difference
-  betweeen BoxedTuple and ConstraintTuple (same OccName!), so tuples
+  between BoxedTuple and ConstraintTuple (same OccName!), so tuples
   are not serialised into interface files using OccNames at all.
 -}
 
diff --git a/compiler/simplCore/Simplify.hs b/compiler/simplCore/Simplify.hs
index b798013e7c..4d31f5b1d1 100644
--- a/compiler/simplCore/Simplify.hs
+++ b/compiler/simplCore/Simplify.hs
@@ -1499,7 +1499,7 @@ Then we want to rewrite (g (h x)) to (k x) and only then try f's rules. If
 we match f's rules against the un-simplified RHS, it won't match.  This
 makes a particularly big difference when superclass selectors are involved:
         op ($p1 ($p2 (df d)))
-We want all this to unravel in one sweeep.
+We want all this to unravel in one sweep.
 
 Note [Avoid redundant simplification]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/compiler/simplCore/simplifier.tib b/compiler/simplCore/simplifier.tib
index 18acd27943..5ffbefedfe 100644
--- a/compiler/simplCore/simplifier.tib
+++ b/compiler/simplCore/simplifier.tib
@@ -75,7 +75,7 @@ a short-hand, not an algorithm.
     (y:ys) -> E1[y,ys]	
     []     -> E2
 @
-Transformations of this kind are almost embarassingly simple.  How could
+Transformations of this kind are almost embarrassingly simple.  How could
 anyone write a paper about them?
 \end{itemize}
 This paper is about humble transformations, and how to implement them. 
diff --git a/compiler/specialise/Specialise.hs b/compiler/specialise/Specialise.hs
index a0c8938d70..bccf600c10 100644
--- a/compiler/specialise/Specialise.hs
+++ b/compiler/specialise/Specialise.hs
@@ -1664,7 +1664,7 @@ have the big, un-optimised of f (albeit specialised) captured in an
 INLINABLE pragma for f_spec, we won't get that optimisation.
 
 So we simply drop INLINABLE pragmas when specialising. It's not really
-a complete solution; ignoring specalisation for now, INLINABLE functions
+a complete solution; ignoring specialisation for now, INLINABLE functions
 don't get properly strictness analysed, for example. But it works well
 for examples involving specialisation, which is the dominant use of
 INLINABLE.  See Trac #4874.
diff --git a/compiler/stranal/DmdAnal.hs b/compiler/stranal/DmdAnal.hs
index 0a731e9481..f7dbdde8a2 100644
--- a/compiler/stranal/DmdAnal.hs
+++ b/compiler/stranal/DmdAnal.hs
@@ -1173,7 +1173,7 @@ binders the CPR property.  Specifically
         fw False x = 3
 
    Of course there is the usual risk of re-boxing: we have 'x' available
-   boxed and unboxed, but we return the unboxed verison for the wrapper to
+   boxed and unboxed, but we return the unboxed version for the wrapper to
    box.  If the wrapper doesn't cancel with its caller, we'll end up
    re-boxing something that we did have available in boxed form.
 
diff --git a/compiler/typecheck/TcSMonad.hs b/compiler/typecheck/TcSMonad.hs
index 9cb2b9b955..b9240424e5 100644
--- a/compiler/typecheck/TcSMonad.hs
+++ b/compiler/typecheck/TcSMonad.hs
@@ -1299,7 +1299,7 @@ did, we would do this:
 This loop goes on for ever and triggers the simpl_loop limit.
 
 Solution: kick out the CDictCan which will have pend_sc = False,
-becuase we've already added its superclasses.  So we won't re-add
+because we've already added its superclasses.  So we won't re-add
 them.  If we forget the pend_sc flag, our cunning scheme for avoiding
 generating superclasses repeatedly will fail.