[m-rev.] diff: fix minor errors in the compiler's notes directory

[Julien Fischer]

Fix minor errors in the compiler's notes directory.

compiler/notes/c_coding_standard.html:
compiler/notes/compiler_design.html:
compiler/notes/reviews.html:
compiler/notes/todo.html:
 	As above.

Julien.

diff --git a/compiler/notes/c_coding_standard.html b/compiler/notes/c_coding_standard.html
index a549a5b..56c1675 100644
--- a/compiler/notes/c_coding_standard.html
+++ b/compiler/notes/c_coding_standard.html
@@ -700,6 +700,6 @@ comments?  see our
  <a href="http://www.mercurylang.org/contact.html">contact</a> page.<br>

  Note: This coding standard is an amalgam of suggestions from the
-entire Mercury team, not ncessarily the opinion of any single author.
+entire Mercury team, not necessarily the opinion of any single author.
  </body>
  </html>
diff --git a/compiler/notes/coding_standards.html b/compiler/notes/coding_standards.html
index 6b58752..4b607ef 100644
--- a/compiler/notes/coding_standards.html
+++ b/compiler/notes/coding_standards.html
@@ -58,7 +58,7 @@ what the field represents.
  <p>

  Any user-visible changes such as new compiler options or new features
-should be documented in appropriate section of the Mercury documentation
+should be documented in the appropriate section(s) of the Mercury documentation
  (usually the Mercury User's Guide and/or the Mercury Reference Manual).
  Any major new features should be documented in the NEWS file,
  as should even small changes to the library interface,
@@ -131,7 +131,7 @@ The conventional IO state variable name is <code>!IO</code>.
  Code should check for both erroneous inputs from the user
  and also invalid data being passed from other parts of the Mercury compiler.
  You should also always check to make sure that
-the routines that you call have succeed;
+the routines that you call have succeeded;
  make sure you don't silently ignore failures.
  (This last point almost goes without saying in Mercury,
  but is particularly important to bear in mind
@@ -460,7 +460,7 @@ since this makes it harder to resort the group with a single editor command.
  The descriptive comment for any predicate or function that occurs in the
  interface of a standard library module must be positioned above the predicate
  or function declaration.
-It should be formatted as in following example:
+It should be formatted as in the following example:

  <pre>

diff --git a/compiler/notes/compiler_design.html b/compiler/notes/compiler_design.html
index 3948964..59447b4 100644
--- a/compiler/notes/compiler_design.html
+++ b/compiler/notes/compiler_design.html
@@ -183,7 +183,7 @@ Option handling is part of the libs.m package.
  <p>

  The command-line options are defined in the module options.m.
-mercury_compile.m calls library/getopt.m, passing the predicates
+mercury_compile.m calls library/getopt_io.m, passing the predicates
  defined in options.m as arguments, to parse them.  It then invokes
  handle_options.m to postprocess the option set. The results are
  represented using the type globals, defined in globals.m.
@@ -332,7 +332,7 @@ such as pretty-printing.
  	for manipulating mutable variables,
  	prog_event.m contains utility predicates for working with events,
  	while error_util.m contains predicates
-	for printing nicely formatting error messages.
+	for printing nicely formatted error messages.

  <li><p> imports and exports are handled at this point (modules.m)

diff --git a/compiler/notes/reviews.html b/compiler/notes/reviews.html
index 4adf107..31073be 100644
--- a/compiler/notes/reviews.html
+++ b/compiler/notes/reviews.html
@@ -50,7 +50,7 @@ need to be reviewed.
          documentation</a>,
          or create one or more commeits and mail them to us using either
      -->
-        create one or more commeits and mail them to us using either
+        create one or more commits and mail them to us using either
          <code>git diff</code> or by creating series of commits and using
          <code>git format-patch</code> (see the git documentation for
          details).
@@ -118,7 +118,7 @@ If adding a new feature, this is a good place to describe the feature,
  how it works, how to turn it on and off, and any present limitations of
  the feature (note that all this should also be documented within the
  change, as well).  If fixing a bug, describe both the bug and the fix.  If
-the bug is in the bugtracker, also include the bug's number for reference.
+the bug is in the bug tracker, also include the bug's number for reference.

  <p>

diff --git a/compiler/notes/todo.html b/compiler/notes/todo.html
index 1ec3362..2025366 100644
--- a/compiler/notes/todo.html
+++ b/compiler/notes/todo.html
@@ -196,7 +196,7 @@ For more information on any of these issues see our
  </pre>
       is considered det.

-<li> turn chains of if-then-elses into switchs where possible.
+<li> turn chains of if-then-elses into switches where possible.
  	[done by fjh, but not committed; zs not convinced that
  	this is a good idea]