CallArity: Various comment fixes

1 files changed, 10 insertions, 10 deletions

diff --git a/compiler/GHC/Core/Opt/CallArity.hs b/compiler/GHC/Core/Opt/CallArity.hs
index aa1f2ee5a1..3af862c570 100644
--- a/compiler/GHC/Core/Opt/CallArity.hs
+++ b/compiler/GHC/Core/Opt/CallArity.hs
@@ -35,7 +35,7 @@ import Control.Arrow ( first, second )
 Note [Call Arity: The goal]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The goal of this analysis is to find out if we can eta-expand a local function,
+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 this code,
 which comes up when we implement foldl using foldr, and do list fusion:
 
@@ -67,11 +67,11 @@ What we want to know for a variable
 
 For every let-bound variable we'd like to know:
   1. A lower bound on the arity of all calls to the variable, and
-  2. whether the variable is being called at most once or possible multiple
+  2. whether the variable is being called at most once or possibly multiple
      times.
 
-It is always ok to lower the arity, or pretend that there are multiple calls.
-In particular, "Minimum arity 0 and possible called multiple times" is always
+It is always okay to lower the arity, or pretend that there are multiple calls.
+In particular, "Minimum arity 0 and possibly called multiple times" is always
 correct.
 
 
@@ -83,12 +83,12 @@ obtain bits of information:
 
  I.  The arity analysis:
      For every variable, whether it is absent, or called,
-     and if called, which what arity.
+     and if called, with what arity.
 
  II. The Co-Called analysis:
      For every two variables, whether there is a possibility that both are being
      called.
-     We obtain as a special case: For every variables, whether there is a
+     We obtain as a special case: For every variable, whether there is a
      possibility that it is being called twice.
 
 For efficiency reasons, we gather this information only for a set of
@@ -100,16 +100,16 @@ the information about what variables are being called once or multiple times.
 Note [Analysis I: The arity analysis]
 ------------------------------------
 
-The arity analysis is quite straight forward: The information about an
+The arity analysis is quite straightforward: The information about an
 expression is an
     VarEnv Arity
 where absent variables are bound to Nothing and otherwise to a lower bound to
 their arity.
 
 When we analyze an expression, we analyze it with a given context arity.
-Lambdas decrease and applications increase the incoming arity. Analysizing a
-variable will put that arity in the environment. In lets or cases all the
-results from the various subexpressions are lubed, which takes the point-wise
+Lambdas decrease and applications increase the incoming arity. Analysing a
+variable will put that arity in the environment. In `let`s or `case`s all the
+results from the various subexpressions are lub'd, which takes the point-wise
 minimum (considering Nothing an infinity).