[commit: ghc] master: Typos in comments (ce335ce)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/ghc

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/ce335cee31de24d817246a87935bb9ffd21168f9/ghc

>---------------------------------------------------------------

commit ce335cee31de24d817246a87935bb9ffd21168f9
Author: Gabor Greif <ggreif at gmail.com>
Date:   Tue Mar 25 22:52:13 2014 +0100

    Typos in comments


>---------------------------------------------------------------

ce335cee31de24d817246a87935bb9ffd21168f9
 compiler/simplCore/Simplify.lhs    |    4 ++--
 compiler/typecheck/TcCanonical.lhs |    2 +-
 compiler/typecheck/TcSimplify.lhs  |    4 ++--
 compiler/typecheck/TcValidity.lhs  |    4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/compiler/simplCore/Simplify.lhs b/compiler/simplCore/Simplify.lhs
index 75ed48f..02470be 100644
--- a/compiler/simplCore/Simplify.lhs
+++ b/compiler/simplCore/Simplify.lhs
@@ -1717,7 +1717,7 @@ or
              exceptions or divergence
 or
         (c) 'x' is used strictly in the body, and 'e' is a variable
-            Then we can just subtitute 'e' for 'x' in the body.
+            Then we can just substitute 'e' for 'x' in the body.
             See Note [Eliminating redundant seqs]
 
 For (b), the "not used at all" test is important.  Consider
@@ -1744,7 +1744,7 @@ transform
 which is might be puzzling if 'x' currently lambda-bound, but later gets
 let-bound to (error "good").
 
-Nevertheless, the paper "A semantics for impecise exceptions" allows
+Nevertheless, the paper "A semantics for imprecise exceptions" allows
 this transformation. If you want to fix the evaluation order, use
 'pseq'.  See Trac #8900 for an example where the loss of this
 transformation bit us in practice. 
diff --git a/compiler/typecheck/TcCanonical.lhs b/compiler/typecheck/TcCanonical.lhs
index 3e23756..cc53d03 100644
--- a/compiler/typecheck/TcCanonical.lhs
+++ b/compiler/typecheck/TcCanonical.lhs
@@ -1303,7 +1303,7 @@ NB: it is important that the types s1,s2 are flattened and zonked
 
 NB: it's important that the new CIrredCan goes in the inert set rather
 than back into the work list. We used to do the latter, but that led
-to an infinite loop when we encountered it again, and put it back it
+to an infinite loop when we encountered it again, and put it back in
 the work list again.
 
 See also Note [Kind orientation for CTyEqCan] and
diff --git a/compiler/typecheck/TcSimplify.lhs b/compiler/typecheck/TcSimplify.lhs
index fa7c75d..c4308f6 100644
--- a/compiler/typecheck/TcSimplify.lhs
+++ b/compiler/typecheck/TcSimplify.lhs
@@ -495,9 +495,9 @@ This only half-works, but then let-generalisation only half-works.
 
 See note [Simplifying RULE constraints] in TcRule
 
-Note [RULE quanfification over equalities]
+Note [RULE quantification over equalities]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Decideing which equalities to quantify over is tricky:
+Deciding which equalities to quantify over is tricky:
  * We do not want to quantify over insoluble equalities (Int ~ Bool)
     (a) because we prefer to report a LHS type error
     (b) because if such things end up in 'givens' we get a bogus
diff --git a/compiler/typecheck/TcValidity.lhs b/compiler/typecheck/TcValidity.lhs
index d4fc09e..84453eb 100644
--- a/compiler/typecheck/TcValidity.lhs
+++ b/compiler/typecheck/TcValidity.lhs
@@ -443,8 +443,8 @@ instances is a bit subtle.  If we allowed
   instance (?x::Int, Eq a) => Foo [a] where ...
 then when we saw
      (e :: (?x::Int) => t)
-it would be unclear how to discharge all the potential usas of the ?x
-in e.  For example, a constraint Foo [Int] might come out of e,and
+it would be unclear how to discharge all the potential uses of the ?x
+in e.  For example, a constraint Foo [Int] might come out of e, and
 applying the instance decl would show up two uses of ?x.  Trac #8912.
 
 \begin{code}