typos

compiler/basicTypes/MkId.lhs

@@ -291,7 +291,7 @@ mkDictSelId dflags no_unf name clas
 	                                else mkImplicitUnfolding dflags rhs)
 		   -- In module where class op is defined, we must add
 		   -- the unfolding, even though it'll never be inlined
-		   -- becuase we use that to generate a top-level binding
+		   -- because we use that to generate a top-level binding
 		   -- for the ClassOp
 
     info | new_tycon = base_info `setInlinePragInfo` alwaysInlinePragma

compiler/basicTypes/SrcLoc.lhs

@@ -257,7 +257,7 @@ data RealSrcSpan
           srcSpanLine     :: {-# UNPACK #-} !Int,
           srcSpanCol      :: {-# UNPACK #-} !Int
         }
-  deriving (Eq, Typeable, Show) -- Show is used by Lexer.x, becuase we
+  deriving (Eq, Typeable, Show) -- Show is used by Lexer.x, because we
                                 -- derive Show for Token
 
 data SrcSpan =
@@ -265,7 +265,7 @@ data SrcSpan =
   | UnhelpfulSpan !FastString   -- Just a general indication
                                 -- also used to indicate an empty span
 
-  deriving (Eq, Typeable, Show) -- Show is used by Lexer.x, becuase we
+  deriving (Eq, Typeable, Show) -- Show is used by Lexer.x, because we
                                 -- derive Show for Token
 
 -- | Built-in "bad" 'SrcSpan's for common sources of location uncertainty

compiler/basicTypes/Var.lhs

@@ -352,7 +352,7 @@ idDetails (Id { id_details = details }) = details
 idDetails other 	       	        = pprPanic "idDetails" (ppr other)
 
 -- The next three have a 'Var' suffix even though they always build
--- Ids, becuase Id.lhs uses 'mkGlobalId' etc with different types
+-- Ids, because Id.lhs uses 'mkGlobalId' etc with different types
 mkGlobalVar :: IdDetails -> Name -> Type -> IdInfo -> Id
 mkGlobalVar details name ty info
   = mk_id name ty GlobalId details info

compiler/coreSyn/CoreArity.lhs

@@ -202,7 +202,7 @@ slightly more complicated, does) turn into
 
    blah = op (\eta. ($dfList dCInt |> sym co) eta)
 
-and now it is *much* harder for the op/$dfList rule to fire, becuase
+and now it is *much* harder for the op/$dfList rule to fire, because
 exprIsConApp_maybe won't hold of the argument to op.  I considered
 trying to *make* it hold, but it's tricky and I gave up.
 

compiler/coreSyn/CoreLint.lhs

@@ -144,7 +144,7 @@ lintCoreBindings binds
     -- allow this at top level:
     --    M.n{r3}  = ...
     --    M.n{r29} = ...
-    -- becuase they both get the same linker symbol
+    -- because they both get the same linker symbol
     ext_dups = snd (removeDups ord_ext (map Var.varName binders))
     ord_ext n1 n2 | Just m1 <- nameModule_maybe n1
                   , Just m2 <- nameModule_maybe n2

compiler/coreSyn/CoreSubst.lhs

@@ -436,7 +436,7 @@ substBind subst (Rec pairs) = (subst', Rec (bndrs' `zip` rhss'))
 
 \begin{code}
 -- | De-shadowing the program is sometimes a useful pre-pass. It can be done simply
--- by running over the bindings with an empty substitution, becuase substitution
+-- by running over the bindings with an empty substitution, because substitution
 -- returns a result that has no-shadowing guaranteed.
 --
 -- (Actually, within a single /type/ there might still be shadowing, because 
@@ -868,7 +868,7 @@ simpleOptExpr :: CoreExpr -> CoreExpr
 -- We also inline bindings that bind a Eq# box: see
 -- See Note [Optimise coercion boxes agressively].
 --
--- The result is NOT guaranteed occurence-analysed, becuase
+-- The result is NOT guaranteed occurence-analysed, because
 -- in  (let x = y in ....) we substitute for x; so y's occ-info
 -- may change radically
 

compiler/coreSyn/CoreUtils.lhs

@@ -525,7 +525,7 @@ There used to be a gruesome test for (hasNoBinding v) in the
 Var case:
         exprIsTrivial (Var v) | hasNoBinding v = idArity v == 0
 The idea here is that a constructor worker, like \$wJust, is
-really short for (\x -> \$wJust x), becuase \$wJust has no binding.
+really short for (\x -> \$wJust x), because \$wJust has no binding.
 So it should be treated like a lambda.  Ditto unsaturated primops.
 But now constructor workers are not "have-no-binding" Ids.  And
 completely un-applied primops and foreign-call Ids are sufficiently

compiler/deSugar/Desugar.lhs

@@ -371,7 +371,7 @@ dsRule (L loc (HsRule name act vars lhs _tv_lhs rhs _fv_rhs))
 		Right (final_bndrs, fn_id, args) -> do
 	
 	{ let is_local = isLocalId fn_id
-		-- NB: isLocalId is False of implicit Ids.  This is good becuase
+		-- NB: isLocalId is False of implicit Ids.  This is good because
 		-- we don't want to attach rules to the bindings of implicit Ids, 
 		-- because they don't show up in the bindings until just before code gen
 	      fn_name   = idName fn_id

compiler/deSugar/DsBinds.lhs

@@ -662,8 +662,8 @@ It's true that this *is* a more specialised type, but the rule
 we get is something like this:
 	f_spec d = f
 	RULE: f = f_spec d
-Note that the rule is bogus, becuase it mentions a 'd' that is
-not bound on the LHS!  But it's a silly specialisation anyway, becuase
+Note that the rule is bogus, because it mentions a 'd' that is
+not bound on the LHS!  But it's a silly specialisation anyway, because
 the constraint is unused.  We could bind 'd' to (error "unused")
 but it seems better to reject the program because it's almost certainly
 a mistake.  That's what the isDeadBinder call detects.

compiler/deSugar/DsExpr.lhs

@@ -820,7 +820,7 @@ conversionNames
   = [ toIntegerName, toRationalName
     , fromIntegralName, realToFracName ]
  -- We can't easily add fromIntegerName, fromRationalName,
- -- becuase they are generated by literals
+ -- because they are generated by literals
 \end{code}
 
 %************************************************************************

compiler/deSugar/DsMeta.hs

@@ -8,7 +8,7 @@
 -- CoreExpr's of the "smart constructors" of the Meta.Exp datatype.
 --
 -- It also defines a bunch of knownKeyNames, in the same way as is done
--- in prelude/PrelNames.  It's much more convenient to do it here, becuase
+-- in prelude/PrelNames.  It's much more convenient to do it here, because
 -- otherwise we have to recompile PrelNames whenever we add a Name, which is
 -- a Royal Pain (triggers other recompilation).
 -----------------------------------------------------------------------------
@@ -351,7 +351,7 @@ repClsInstD (ClsInstDecl { cid_poly_ty = ty, cid_binds = binds
             -- appear in the resulting data structure
 	    --
 	    -- But we do NOT bring the binders of 'binds' into scope
-	    -- becuase they are properly regarded as occurrences
+	    -- because they are properly regarded as occurrences
 	    -- For example, the method names should be bound to
 	    -- the selector Ids, not to fresh names (Trac #5410)
 	    --
@@ -1876,7 +1876,7 @@ mk_string s = return $ HsString s
 repOverloadedLiteral :: HsOverLit Name -> DsM (Core TH.Lit)
 repOverloadedLiteral (OverLit { ol_val = val})
   = do { lit <- mk_lit val; repLiteral lit }
-	-- The type Rational will be in the environment, becuase
+	-- The type Rational will be in the environment, because
 	-- the smart constructor 'TH.Syntax.rationalL' uses it in its type,
 	-- and rationalL is sucked in when any TH stuff is used
 

compiler/deSugar/DsUtils.lhs

@@ -291,7 +291,7 @@ mkCoAlgCaseMatchResult dflags var ty match_alts
   = MatchResult fail_flag mk_case
   where
     tycon = dataConTyCon con1
-	-- [Interesting: becuase of GADTs, we can't rely on the type of 
+	-- [Interesting: because of GADTs, we can't rely on the type of 
 	--  the scrutinised Id to be sufficiently refined to have a TyCon in it]
 
 	-- Stuff for newtype

compiler/deSugar/MatchLit.lhs

@@ -113,7 +113,7 @@ dsOverLit' dflags (OverLit { ol_val = val, ol_rebindable = rebindable
 Note [Literal short cut]
 ~~~~~~~~~~~~~~~~~~~~~~~~
 The type checker tries to do this short-cutting as early as possible, but 
-becuase of unification etc, more information is available to the desugarer.
+because of unification etc, more information is available to the desugarer.
 And where it's possible to generate the correct literal right away, it's
 much better do do so.
 

compiler/iface/IfaceSyn.lhs

@@ -206,7 +206,7 @@ type IfaceAnnTarget = AnnTarget OccName
 
 -- We only serialise the IdDetails of top-level Ids, and even then
 -- we only need a very limited selection.  Notably, none of the
--- implicit ones are needed here, becuase they are not put it
+-- implicit ones are needed here, because they are not put it
 -- interface files
 
 data IfaceIdDetails

compiler/main/TidyPgm.lhs

@@ -476,7 +476,7 @@ Note [Don't attempt to trim data types]
 For some time GHC tried to avoid exporting the data constructors
 of a data type if it wasn't strictly necessary to do so; see Trac #835.
 But "strictly necessary" accumulated a longer and longer list 
-of execeptions, and finally I gave up the battle:
+of exceptions, and finally I gave up the battle:
 
     commit 9a20e540754fc2af74c2e7392f2786a81d8d5f11
     Author: Simon Peyton Jones <simonpj@microsoft.com>
@@ -525,7 +525,7 @@ Id still makes sense.]
 
 At one time I tried injecting the implicit bindings *early*, at the
 beginning of SimplCore.  But that gave rise to real difficulty,
-becuase GlobalIds are supposed to have *fixed* IdInfo, but the
+because GlobalIds are supposed to have *fixed* IdInfo, but the
 simplifier and other core-to-core passes mess with IdInfo all the
 time.  The straw that broke the camels back was when a class selector
 got the wrong arity -- ie the simplifier gave it arity 2, whereas

compiler/nativeGen/X86/CodeGen.hs

@@ -749,7 +749,7 @@ getRegister' _ is32Bit (CmmMachOp mop [x, y]) = do -- dyadic MachOps
       * so we can either:
         - do y first, put its result in a fresh tmp, then copy it to %ecx later
         - do y second and put its result into %ecx.  x gets placed in a fresh
-          tmp.  This is likely to be better, becuase the reg alloc can
+          tmp.  This is likely to be better, because the reg alloc can
           eliminate this reg->reg move here (it won't eliminate the other one,
           because the move is into the fixed %ecx).
     -}

compiler/prelude/TysPrim.lhs

@@ -241,7 +241,7 @@ funTyCon = mkFunTyCon funTyConName $
         -- You might think that (->) should have type (?? -> ? -> *), and you'd be right
 	-- But if we do that we get kind errors when saying
 	--	instance Control.Arrow (->)
-	-- becuase the expected kind is (*->*->*).  The trouble is that the
+	-- because the expected kind is (*->*->*).  The trouble is that the
 	-- expected/actual stuff in the unifier does not go contra-variant, whereas
 	-- the kind sub-typing does.  Sigh.  It really only matters if you use (->) in
 	-- a prefix way, thus:  (->) Int# Int#.  And this is unusual.
@@ -653,7 +653,7 @@ The type constructor Any of kind forall k. k -> k has these properties:
   * It is a *closed* type family, with no instances.  This means that
     if   ty :: '(k1, k2)  we add a given coercion
              g :: ty ~ (Fst ty, Snd ty)
-    If Any was a *data* type, then we'd get inconsistency becuase 'ty'
+    If Any was a *data* type, then we'd get inconsistency because 'ty'
     could be (Any '(k1,k2)) and then we'd have an equality with Any on
     one side and '(,) on the other
 

compiler/rename/RnEnv.lhs

@@ -440,7 +440,7 @@ Thus:
     instance C S where
       data G S = Y1 | Y2
 Even though there are two G's in scope (M.G and Blib.G), the occurence
-of 'G' in the 'instance C S' decl is unambiguous, becuase C has only
+of 'G' in the 'instance C S' decl is unambiguous, because C has only
 one associated type called G. This is exactly what happens for methods,
 and it is only consistent to do the same thing for types. That's the
 role of the function lookupTcdName; the (Maybe Name) give the class of

compiler/rename/RnExpr.lhs

@@ -1056,7 +1056,7 @@ rn_rec_stmt _ all_bndrs (L loc (LetStmt (HsValBinds binds'))) _ = do
   return [(duDefs du_binds, allUses du_binds, 
 	   emptyNameSet, L loc (LetStmt (HsValBinds binds')))]
 
--- no RecStmt case becuase they get flattened above when doing the LHSes
+-- no RecStmt case because they get flattened above when doing the LHSes
 rn_rec_stmt _ _ stmt@(L _ (RecStmt {})) _
   = pprPanic "rn_rec_stmt: RecStmt" (ppr stmt)
 

compiler/rename/RnNames.lhs

@@ -905,7 +905,7 @@ What does M export?  AvailTC F [FInt]
 The former is strictly right because F isn't defined in this module.
 But then you can never do an explicit import of M, thus
     import M( F( FInt ) )
-becuase F isn't exported by M.  Nor can you import FInt alone from here
+because F isn't exported by M.  Nor can you import FInt alone from here
     import M( FInt )
 because we don't have syntax to support that.  (It looks like an import of 
 the type FInt.)
@@ -1334,7 +1334,7 @@ each import declaration, what stuff brought into scope by that
 declaration is actually used in the module.
 
 The SrcLoc is the location of the END of a particular 'import'
-declaration.  Why *END*?  Becuase we don't want to get confused
+declaration.  Why *END*?  Because we don't want to get confused
 by the implicit Prelude import. Consider (Trac #7476) the module
     import Foo( foo )
     main = print foo