[commit: ghc] master: Fix comment typos (919e930)

[git at git.haskell.org]

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

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

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

commit 919e9303c1ce0fffc5d09b6875f17cf9b1f5167d
Author: Jan Stolarek <jan.stolarek at p.lodz.pl>
Date:   Fri Oct 31 10:31:40 2014 +0100

    Fix comment typos


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

919e9303c1ce0fffc5d09b6875f17cf9b1f5167d
 compiler/simplCore/CallArity.hs  | 4 ++--
 compiler/simplCore/SetLevels.lhs | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/compiler/simplCore/CallArity.hs b/compiler/simplCore/CallArity.hs
index bead230..5ee5fe2 100644
--- a/compiler/simplCore/CallArity.hs
+++ b/compiler/simplCore/CallArity.hs
@@ -33,7 +33,7 @@ Note [Call Arity: The goal]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The goal of this analysis is to find out if we can eta-expand a local function,
-based on how it is being called. The motivating example is code this this,
+based on how it is being called. The motivating example is this code,
 which comes up when we implement foldl using foldr, and do list fusion:
 
     let go = \x -> let d = case ... of
@@ -46,7 +46,7 @@ If we do not eta-expand `go` to have arity 2, we are going to allocate a lot of
 partial function applications, which would be bad.
 
 The function `go` has a type of arity two, but only one lambda is manifest.
-Further more, an analysis that only looks at the RHS of go cannot be sufficient
+Furthermore, an analysis that only looks at the RHS of go cannot be sufficient
 to eta-expand go: If `go` is ever called with one argument (and the result used
 multiple times), we would be doing the work in `...` multiple times.
 
diff --git a/compiler/simplCore/SetLevels.lhs b/compiler/simplCore/SetLevels.lhs
index 5f63096..e5cd42e 100644
--- a/compiler/simplCore/SetLevels.lhs
+++ b/compiler/simplCore/SetLevels.lhs
@@ -331,7 +331,7 @@ lvlExpr env expr@(_, AnnApp _ _) = do
 -- We don't split adjacent lambdas.  That is, given
 --      \x y -> (x+1,y)
 -- we don't float to give
---      \x -> let v = x+y in \y -> (v,y)
+--      \x -> let v = x+1 in \y -> (v,y)
 -- Why not?  Because partial applications are fairly rare, and splitting
 -- lambdas makes them more expensive.