Index: doc/theses/andrew_beach_MMath/implement.tex
===================================================================
--- doc/theses/andrew_beach_MMath/implement.tex	(revision 13afd0cbeee1ddb3264d47bfd3555f7d1357ab72)
+++ doc/theses/andrew_beach_MMath/implement.tex	(revision ff3be413d3864c7cd203c65ed41c36ba2938009c)
@@ -51,5 +51,5 @@
 The problem is that a type id may appear in multiple TUs that compose a
 program (see \autoref{ss:VirtualTable}); so the initial solution would seem
-to be make it external in each translation unit. Honever, the type id must
+to be make it external in each translation unit. Hovever, the type id must
 have a declaration in (exactly) one of the TUs to create the storage.
 No other declaration related to the virtual type has this property, so doing
@@ -183,5 +183,5 @@
 The second section are all the virtual members of the parent, in the same
 order as they appear in the parent's virtual table. Note that the type may
-change slightly as references to the ``this" will change. This is limited to
+change slightly as references to the ``this" change. This is limited to
 inside pointers/references and via function pointers so that the size (and
 hence the offsets) are the same.
@@ -216,10 +216,10 @@
 type's alignment, is set using an @alignof@ expression.
 
-Most of these tools are already inside the compiler. Using the is a simple
-code transformation early on in compilation allows most of that work to be
+Most of these tools are already inside the compiler. Using simple
+code transformations early on in compilation, allows most of that work to be
 handed off to the existing tools. \autoref{f:VirtualTableTransformation}
 shows an example transformation, this example shows an exception virtual table.
-It also shows the transformation on the full declaration,
-for a forward declaration the @extern@ keyword is preserved and the
+It also shows the transformation on the full declaration.
+For a forward declaration, the @extern@ keyword is preserved and the
 initializer is not added.
 
@@ -333,5 +333,5 @@
 the exceptions themselves and the virtual system interactions.
 
-Creating an exception type is just a matter of preppending the field  
+Creating an exception type is just a matter of prepending the field  
 with the virtual table pointer to the list of the fields
 (see \autoref{f:ExceptionTypeTransformation}).
@@ -364,17 +364,17 @@
 the types of the virtual table and the type id,
 are generated when the virtual type (the exception) is first found.
-The type id (the instance) is generated with the exception if it is
+The type id (the instance) is generated with the exception, if it is
 a monomorphic type.
-However if the exception is polymorphic then a different type id has to
-be generated for every instance. In this case generation is delayed
+However, if the exception is polymorphic, then a different type id has to
+be generated for every instance. In this case, generation is delayed
 until a virtual table is created.
 % There are actually some problems with this, which is why it is not used
 % for monomorphic types.
-When a virtual table is created and initialized two functions are created
+When a virtual table is created and initialized, two functions are created
 to fill in the list of virtual members.
-The first is a copy function which adapts the exception's copy constructor
+The first is a copy function that adapts the exception's copy constructor
 to work with pointers, avoiding some issues with the current copy constructor
 interface.
-Second is the msg function, which returns a C-string with the type's name,
+Second is the msg function that returns a C-string with the type's name,
 including any polymorphic parameters.
 
@@ -405,5 +405,5 @@
 Unwinding across multiple stack frames is more complex because that
 information is no longer contained within the current function.
-With seperate compilation,
+With separate compilation,
 a function does not know its callers nor their frame layout.
 Even using the return address, that information is encoded in terms of
@@ -479,5 +479,5 @@
 
 To get full unwinding support, all of these features must be handled directly
-in assembly and assembler directives; partiularly the cfi directives
+in assembly and assembler directives; particularly the cfi directives
 \snake{.cfi_lsda} and \snake{.cfi_personality}.
 
@@ -894,5 +894,5 @@
 
 \autoref{f:ResumptionTransformation} shows the pattern used to transform
-a \CFA try statement with catch clauses into the approprate C functions.
+a \CFA try statement with catch clauses into the appropriate C functions.
 \todo{Explain the Resumption Transformation figure.}