Small doc improvements

doc/introduction.rst

@@ -10,13 +10,13 @@ Like yacc, it takes a file containing an annotated BNF specification of a gramma
   single: yacc
 
 Happy is flexible: you can have several Happy parsers in the same program, and each parser may have multiple entry points.
-Happy can work in conjunction with a lexical analyser supplied by the user (either hand-written or generated by another program),
+Happy can work in conjunction with a lexical analyser supplied by the user (either handwritten or generated by another program),
 or it can parse a stream of characters directly (but this isn't practical in most cases).
 In a future version we hope to include a lexical analyser generator with Happy as a single package.
 
 Parsers generated by Happy are fast;
 generally faster than an equivalent parser written using parsing combinators or similar tools.
-Furthermore, any future improvements made to Happy will benefit an existing grammar, without need for a rewrite.
+Furthermore, any future improvements made to Happy will benefit an existing grammar, without the need for a rewrite.
 
 Happy is sufficiently powerful to parse full Haskell --- `GHC <http://www.haskell.org/ghc>`__ itself uses a Happy parser.
 
@@ -52,7 +52,7 @@ The types of parser supported are:
    This is the fastest/smallest option for GHC users.
    If you're using GHC, the optimum flag settings are ``-agc`` (see :ref:`Invoking <sec-invoking>`).
 
-Happy can also generate parsers which will dump debugging information at run time,
+Happy can also generate parsers which will dump debugging information at runtime,
 showing state transitions and the input tokens to the parser.
 
 .. _sec-compatibility:

doc/tips.rst

@@ -36,7 +36,7 @@ so here's some tips on making things more sensible:
 -  Include as little code as possible in the module trailer.
    This code is included verbatim in the generated parser, so if any of it can go in a separate module, do so.
 
--  Give :index:`type signatures <single: type; signatures in grammar>` for everything (see :ref:`Type Signatures <sec-type-signatures>`.
+-  Give :index:`type signatures <single: type; signatures in grammar>` for everything (see :ref:`Type Signatures <sec-type-signatures>`).
    This is reported to improve things by about 50%.
    If there is a type signature for every single non-terminal in the grammar, then Happy automatically generates type signatures for most functions in the parser.
 
@@ -62,7 +62,7 @@ An info file (generated by the ``-i`` option) can be helpful here.
 .. index::
    single: type; signatures in grammar
 
-Type signature sometimes help by pinning down the particular error to the place where the mistake is made, not half way down the file.
+Type signatures sometimes help by pinning down the particular error to the place where the mistake is made, not halfway down the file.
 For each production in the grammar, there's a bit of code in the generated file that looks like this:
 
 .. code-block:: haskell

doc/using.rst

@@ -30,7 +30,7 @@ In a grammar file, Haskell code is always contained between curly braces to dist
 
 In this case, the parser will be a standalone program so we'll call the module ``Main``.
 
-Next comes a couple of declarations:
+Next come a couple of declarations:
 
 .. code-block:: none
 
@@ -341,7 +341,7 @@ Sequences with separators
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A common type of sequence is one with a *separator*:
-for instance function bodies in C consist of statements separated by semicolons.
+for instance, function bodies in C consist of statements separated by semicolons.
 To parse this kind of sequence we use a production like this:
 
 .. code-block:: none
@@ -1058,7 +1058,7 @@ the use of the two-action form of the ``%error`` directive
 The directive specifies a pair of functions ``abort`` and ``report``
 which are necessary to handle multiple parse errors.
 
-The generated parser parses errorneous input such as ``1+;+1;(1+;1`` as
+The generated parser parses erroneous input such as ``1+;+1;(1+;1`` as
 ``["1 + catch", "catch + 1", "catch", "1"]``, with one list element per parsed
 statement.
 To a first approximation, one can think of ``catch`` as standing in for the
@@ -1119,7 +1119,7 @@ A couple of notes:
 
 Note that defining a good AST representation for syntax errors is entirely up
 to the user of happy; the example above simply emitted the string ``catch``
-whenever it stands-in an for an errorneous AST node.
+whenever it stands-in an for an erroneous AST node.
 A more reasonable implementation would be similar to typed holes in GHC.
 
 .. _sec-multiple-parsers: