Index: doc/theses/andrew_beach_MMath/existing.tex
===================================================================
--- doc/theses/andrew_beach_MMath/existing.tex	(revision 5438e41a103bfafb23784bfa350297aa8b943faf)
+++ doc/theses/andrew_beach_MMath/existing.tex	(revision f42a6b855873c132f4969475fb95578812619238)
@@ -10,6 +10,5 @@
 
 Only those \CFA features pertaining to this thesis are discussed.
-% Also, only new features of \CFA will be discussed,
-A familiarity with
+Also, only new features of \CFA will be discussed, a familiarity with
 C or C-like languages is assumed.
 
@@ -17,9 +16,9 @@
 \CFA has extensive overloading, allowing multiple definitions of the same name
 to be defined~\cite{Moss18}.
-\begin{lstlisting}[language=CFA,{moredelim=**[is][\color{red}]{@}{@}}]
-char @i@; int @i@; double @i@;
-int @f@(); double @f@();
-void @g@( int ); void @g@( double );
-\end{lstlisting}
+\begin{cfa}
+char i; int i; double i;
+int f(); double f();
+void g( int ); void g( double );
+\end{cfa}
 This feature requires name mangling so the assembly symbols are unique for
 different overloads. For compatibility with names in C, there is also a syntax
@@ -63,5 +62,5 @@
 int && rri = ri;
 rri = 3;
-&ri = &j; // rebindable
+&ri = &j;
 ri = 5;
 \end{cfa}
@@ -79,6 +78,6 @@
 \end{minipage}
 
-References are intended for pointer situations where dereferencing is the common usage,
-\ie the value is more important than the pointer.
+References are intended to be used when you would use pointers but would
+be dereferencing them (almost) every usage.
 Mutable references may be assigned to by converting them to a pointer
 with a @&@ and then assigning a pointer to them, as in @&ri = &j;@ above
@@ -86,75 +85,70 @@
 \section{Operators}
 
-\CFA implements operator overloading by providing special names, where
-operator usages are translated into function calls using these names.
-An operator name is created by taking the operator symbols and joining them with
+\CFA implements operator overloading by providing special names.
+Operator uses are translated into function calls using these names.
+These names are created by taking the operator symbols and joining them with
 @?@s to show where the arguments go.
 For example,
-infixed multiplication is @?*?@, while prefix dereference is @*?@.
+infixed multiplication is @?*?@ while prefix dereference is @*?@.
 This syntax make it easy to tell the difference between prefix operations
 (such as @++?@) and post-fix operations (@?++@).
-For example, plus and equality operators are defined for a point type.
+
 \begin{cfa}
 point ?+?(point a, point b) { return point{a.x + b.x, a.y + b.y}; }
-int ?==?(point a, point b) { return a.x == b.x && a.y == b.y; }
+bool ?==?(point a, point b) { return a.x == b.x && a.y == b.y; }
 {
 	assert(point{1, 2} + point{3, 4} == point{4, 6});
 }
 \end{cfa}
-Note these special names are not limited to builtin
-operators, and hence, may be used with arbitrary types.
-\begin{cfa}
-double ?+?( int x, point y ); // arbitrary types
-\end{cfa}
-% Some ``near misses", that are that do not match an operator form but looks like
-% it may have been supposed to, will generate warning but otherwise they are
-% left alone.
+Note that these special names are not limited to just being used for these
+operator functions, and may be used name other declarations.
+Some ``near misses", that will not match an operator form but looks like
+it may have been supposed to, will generate wantings but otherwise they are
+left alone.
+
+%\subsection{Constructors and Destructors}
+
+Both constructors and destructors are operators, which means they are
+functions with special operator names rather than type names in \Cpp. The
+special operator names may be used to call the functions explicitly.
+% Placement new means that this is actually equivant to C++.
+
+The special name for a constructor is @?{}@, which comes from the
+initialization syntax in C, \eg @Example e = { ... }@.
+\CFA will generate a constructor call each time a variable is declared,
+passing the initialization arguments to the constructort.
+\begin{cfa}
+struct Example { ... };
+void ?{}(Example & this) { ... }
+{
+	Example a;
+	Example b = {};
+}
+void ?{}(Example & this, char first, int num) { ... }
+{
+	Example c = {'a', 2};
+}
+\end{cfa}
+Both @a@ and @b@ will be initalized with the first constructor,
+while @c@ will be initalized with the second.
+Currently, there is no general way to skip initialation.
+
+% I don't like the \^{} symbol but $^\wedge$ isn't better.
+Similarly destructors use the special name @^?{}@ (the @^@ has no special
+meaning).
+These are a normally called implicitly called on a variable when it goes out
+of scope. They can be called explicitly as well.
+\begin{cfa}
+void ^?{}(Example & this) { ... }
+{
+	Example d;
+} // <- implicit destructor call
+\end{cfa}
+
+Whenever a type is defined, \CFA will create a default zero-argument
+constructor, a copy constructor, a series of argument-per-field constructors
+and a destructor. All user constructors are defined after this.
 Because operators are never part of the type definition they may be added
 at any time, including on built-in types.
-
-%\subsection{Constructors and Destructors}
-
-\CFA also provides constructors and destructors as operators, which means they
-are functions with special operator names rather than type names in \Cpp.
-While constructors and destructions are normally called implicitly by the compiler,
-the special operator names, allow explicit calls.
-
-% Placement new means that this is actually equivalent to C++.
-
-The special name for a constructor is @?{}@, which comes from the
-initialization syntax in C, \eg @Example e = { ... }@.
-\CFA generates a constructor call each time a variable is declared,
-passing the initialization arguments to the constructor.
-\begin{cfa}
-struct Example { ... };
-void ?{}(Example & this) { ... }
-void ?{}(Example & this, char first, int num) { ... }
-Example a;		// implicit constructor calls
-Example b = {};
-Example c = {'a', 2};
-\end{cfa}
-Both @a@ and @b@ are initialized with the first constructor,
-while @c@ is initialized with the second.
-Constructor calls can be replaced with C initialization using special operator \lstinline{@=}.
-\begin{cfa}
-Example d @= {42};
-\end{cfa}
-% I don't like the \^{} symbol but $^\wedge$ isn't better.
-Similarly, destructors use the special name @^?{}@ (the @^@ has no special
-meaning).
-% These are a normally called implicitly called on a variable when it goes out
-% of scope. They can be called explicitly as well.
-\begin{cfa}
-void ^?{}(Example & this) { ... }
-{
-	Example e;	// implicit constructor call
-	^?{}(e);		// explicit destructor call
-	?{}(e);		// explicit constructor call
-} // implicit destructor call
-\end{cfa}
-
-Whenever a type is defined, \CFA creates a default zero-argument
-constructor, a copy constructor, a series of argument-per-field constructors
-and a destructor. All user constructors are defined after this.
 
 \section{Polymorphism}
@@ -208,5 +202,5 @@
 Note, a function named @do_once@ is not required in the scope of @do_twice@ to
 compile it, unlike \Cpp template expansion. Furthermore, call-site inferencing
-allows local replacement of the specific parametric functions needs for a
+allows local replacement of the most specific parametric functions needs for a
 call.
 \begin{cfa}
@@ -224,10 +218,10 @@
 to @do_twice@ and called within it.
 The global definition of @do_once@ is ignored, however if quadruple took a
-@double@ argument, then the global definition would be used instead as it
-is a better match.
+@double@ argument then the global definition would be used instead as it
+would be a better match.
 % Aaron's thesis might be a good reference here.
 
 To avoid typing long lists of assertions, constraints can be collect into
-convenient package called a @trait@, which can then be used in an assertion
+convenient packages called a @trait@, which can then be used in an assertion
 instead of the individual constraints.
 \begin{cfa}
@@ -245,5 +239,5 @@
 functionality, like @sumable@, @listable@, \etc.
 
-Polymorphic structures and unions are defined by qualifying an aggregate type
+Polymorphic structures and unions are defined by qualifying the aggregate type
 with @forall@. The type variables work the same except they are used in field
 declarations instead of parameters, returns, and local variable declarations.
@@ -291,15 +285,14 @@
 coroutine CountUp {
 	unsigned int next;
-};
+}
 CountUp countup;
-for (10) sout | resume(countup).next; // print 10 values
 \end{cfa}
 Each coroutine has a @main@ function, which takes a reference to a coroutine
 object and returns @void@.
 %[numbers=left] Why numbers on this one?
-\begin{cfa}[numbers=left,numberstyle=\scriptsize\sf]
+\begin{cfa}
 void main(CountUp & this) {
-	for (unsigned int up = 0;; ++up) {
-		this.next = up;
+	for (unsigned int next = 0 ; true ; ++next) {
+		next = up;
 		suspend;$\label{suspend}$
 	}
@@ -307,6 +300,6 @@
 \end{cfa}
 In this function, or functions called by this function (helper functions), the
-@suspend@ statement is used to return execution to the coroutine's resumer
-without terminating the coroutine's function(s).
+@suspend@ statement is used to return execution to the coroutine's caller
+without terminating the coroutine's function.
 
 A coroutine is resumed by calling the @resume@ function, \eg @resume(countup)@.
@@ -330,7 +323,7 @@
 exclusion on a monitor object by qualifying an object reference parameter with
 @mutex@.
-\begin{lstlisting}[language=CFA,{moredelim=**[is][\color{red}]{@}{@}}]
-void example(MonitorA & @mutex@ argA, MonitorB & @mutex@ argB);
-\end{lstlisting}
+\begin{cfa}
+void example(MonitorA & mutex argA, MonitorB & mutex argB);
+\end{cfa}
 When the function is called, it implicitly acquires the monitor lock for all of
 the mutex parameters without deadlock.  This semantics means all functions with
@@ -362,5 +355,5 @@
 {
 	StringWorker stringworker; // fork thread running in "main"
-} // implicitly join with thread / wait for completion
+} // <- implicitly join with thread / wait for completion
 \end{cfa}
 The thread main is where a new thread starts execution after a fork operation
Index: doc/theses/andrew_beach_MMath/features.tex
===================================================================
--- doc/theses/andrew_beach_MMath/features.tex	(revision 5438e41a103bfafb23784bfa350297aa8b943faf)
+++ doc/theses/andrew_beach_MMath/features.tex	(revision f42a6b855873c132f4969475fb95578812619238)
@@ -16,43 +16,35 @@
 throw/catch as a particular kind of raise/handle.
 These are the two parts that the user writes and may
-be the only two pieces of the EHM that have any syntax in a language.
+be the only two pieces of the EHM that have any syntax in the language.
 
 \paragraph{Raise}
-The raise is the starting point for exception handling
-by raising an exception, which passes it to
+The raise is the starting point for exception handling. It marks the beginning
+of exception handling by raising an exception, which passes it to
 the EHM.
 
 Some well known examples include the @throw@ statements of \Cpp and Java and
-the \code{Python}{raise} statement of Python. In real systems, a raise may
-perform some other work (such as memory management) but for the
+the \code{Python}{raise} statement from Python. In real systems a raise may
+preform some other work (such as memory management) but for the
 purposes of this overview that can be ignored.
 
 \paragraph{Handle}
-The primary purpose of an EHM is to run some user code to handle a raised
-exception. This code is given, with some other information, in a handler.
+The purpose of most exception operations is to run some user code to handle
+that exception. This code is given, with some other information, in a handler.
 
 A handler has three common features: the previously mentioned user code, a
-region of code it guards, and an exception label/condition that matches
-the raised exception.
+region of code they guard and an exception label/condition that matches
+certain exceptions.
 Only raises inside the guarded region and raising exceptions that match the
 label can be handled by a given handler.
 If multiple handlers could can handle an exception,
-EHMs define a rule to pick one, such as ``best match" or ``first found".
+EHMs will define a rule to pick one, such as ``best match" or ``first found".
 
 The @try@ statements of \Cpp, Java and Python are common examples. All three
-show the common features of guarded region, raise, matching and handler.
-\begin{cfa}
-try {				// guarded region
-	...	 
-	throw exception;	// raise
-	...	 
-} catch( exception ) {	// matching condition, with exception label
-	...				// handler code
-}
-\end{cfa}
+also show another common feature of handlers, they are grouped by the guarded
+region.
 
 \subsection{Propagation}
 After an exception is raised comes what is usually the biggest step for the
-EHM: finding and setting up the handler for execution. The propagation from raise to
+EHM: finding and setting up the handler. The propagation from raise to
 handler can be broken up into three different tasks: searching for a handler,
 matching against the handler and installing the handler.
@@ -60,6 +52,6 @@
 \paragraph{Searching}
 The EHM begins by searching for handlers that might be used to handle
-the exception. The search is restricted to
-handlers that have the raise site in their guarded
+the exception. Searching is usually independent of the exception that was
+thrown as it looks for handlers that have the raise site in their guarded
 region.
 The search includes handlers in the current function, as well as any in
@@ -67,13 +59,14 @@
 
 \paragraph{Matching}
-Each handler found is matched with the raised exception. The exception
-label defines a condition that is used with the exception and decides if
+Each handler found has to be matched with the raised exception. The exception
+label defines a condition that is used with exception and decides if
 there is a match or not.
+
 In languages where the first match is used, this step is intertwined with
-searching; a match check is performed immediately after the search finds
-a handler.
+searching; a match check is preformed immediately after the search finds
+a possible handler.
 
 \paragraph{Installing}
-After a handler is chosen, it must be made ready to run.
+After a handler is chosen it must be made ready to run.
 The implementation can vary widely to fit with the rest of the
 design of the EHM. The installation step might be trivial or it could be
@@ -82,8 +75,8 @@
 
 If a matching handler is not guaranteed to be found, the EHM needs a
-different course of action for this case.
+different course of action for the case where no handler matches.
 This situation only occurs with unchecked exceptions as checked exceptions
-(such as in Java) are guaranteed to find a matching handler.
-The unhandled action is usually very general, such as aborting the program.
+(such as in Java) can make the guarantee.
+This unhandled action is usually very general, such as aborting the program.
 
 \paragraph{Hierarchy}
@@ -92,16 +85,17 @@
 exception hierarchy is a natural extension of the object hierarchy.
 
-Consider the following exception hierarchy:
+Consider the following hierarchy of exceptions:
 \begin{center}
 \input{exception-hierarchy}
 \end{center}
+
 A handler labeled with any given exception can handle exceptions of that
 type or any child type of that exception. The root of the exception hierarchy
-(here \code{C}{exception}) acts as a catch-all, leaf types catch single types,
+(here \code{C}{exception}) acts as a catch-all, leaf types catch single types
 and the exceptions in the middle can be used to catch different groups of
 related exceptions.
 
 This system has some notable advantages, such as multiple levels of grouping,
-the ability for libraries to add new exception types, and the isolation
+the ability for libraries to add new exception types and the isolation
 between different sub-hierarchies.
 This design is used in \CFA even though it is not a object-orientated
@@ -116,5 +110,5 @@
 is usually set up to do most of the work.
 
-The EHM can return control to many different places, where
+The EHM can return control to many different places,
 the most common are after the handler definition (termination)
 and after the raise (resumption).
@@ -123,24 +117,24 @@
 For effective exception handling, additional information is often passed
 from the raise to the handler and back again.
-So far, only communication of the exception's identity is covered.
-A common communication method for passing more information is putting fields into the exception instance
+So far only communication of the exceptions' identity has been covered.
+A common communication method is putting fields into the exception instance
 and giving the handler access to them.
-Using reference fields pointing to data at the raise location allows data to be
+Passing the exception by reference instead of by value can allow data to be
 passed in both directions.
 
 \section{Virtuals}
 Virtual types and casts are not part of \CFA's EHM nor are they required for
-an EHM.
-However, one of the best ways to support an exception hierarchy
+any EHM.
+However, it is one of the best ways to support an exception hierarchy
 is via a virtual hierarchy and dispatch system.
 
-Ideally, the virtual system should have been part of \CFA before the work
+Ideally, the virtual system would have been part of \CFA before the work
 on exception handling began, but unfortunately it was not.
 Hence, only the features and framework needed for the EHM were
-designed and implemented for this thesis. Other features were considered to ensure that
+designed and implemented. Other features were considered to ensure that
 the structure could accommodate other desirable features in the future
-but are not implemented.
-The rest of this section only discusses the implemented subset of the
-virtual-system design.
+but they were not implemented.
+The rest of this section will only discuss the implemented subset of the
+virtual system design.
 
 The virtual system supports multiple ``trees" of types. Each tree is
@@ -158,6 +152,4 @@
 It is important to note that these are virtual members, not virtual methods
 of object-orientated programming, and can be of any type.
-
-\PAB{Need to look at these when done.
 
 \CFA still supports virtual methods as a special case of virtual members.
@@ -173,25 +165,23 @@
 as a hidden field.
 \todo{Might need a diagram for virtual structure.}
-}%
 
 Up until this point the virtual system is similar to ones found in
-object-orientated languages but this is where \CFA diverges. Objects encapsulate a
-single set of methods in each type, universally across the entire program,
-and indeed all programs that use that type definition. Even if a type inherits and adds methods, it still encapsulate a
-single set of methods. In this sense,
-object-oriented types are ``closed" and cannot be altered.
-
-In \CFA, types do not encapsulate any code. Traits are local for each function and
-types can satisfy a local trait, stop satisfying it or, satisfy the same
-trait in a different way at any lexical location in the program where a function is call.
-In this sense, the set of functions/variables that satisfy a trait for a type is ``open" as the set can change at every call site.
+object-orientated languages but this where \CFA diverges. Objects encapsulate a
+single set of behaviours in each type, universally across the entire program,
+and indeed all programs that use that type definition. In this sense, the
+types are ``closed" and cannot be altered.
+
+In \CFA, types do not encapsulate any behaviour. Traits are local and
+types can begin to satisfy a trait, stop satisfying a trait or satisfy the same
+trait in a different way at any lexical location in the program.
+In this sense, they are ``open" as they can change at any time.
 This capability means it is impossible to pick a single set of functions
-that represent a type's implementation across a program.
+that represent the type's implementation across the program.
 
 \CFA side-steps this issue by not having a single virtual table for each
 type. A user can define virtual tables that are filled in at their
 declaration and given a name. Anywhere that name is visible, even if it is
-defined locally inside a function \PAB{What does this mean? (although that means it does not have a
-static lifetime)}, it can be used.
+defined locally inside a function (although that means it does not have a
+static lifetime), it can be used.
 Specifically, a virtual type is ``bound" to a virtual table that
 sets the virtual members for that object. The virtual members can be accessed
@@ -231,5 +221,5 @@
 completing the virtual system). The imaginary assertions would probably come
 from a trait defined by the virtual system, and state that the exception type
-is a virtual type, is a descendant of @exception_t@ (the base exception type),
+is a virtual type, is a descendant of @exception_t@ (the base exception type)
 and note its virtual table type.
 
@@ -251,5 +241,5 @@
 \end{cfa}
 Both traits ensure a pair of types are an exception type, its virtual table
-type,
+type
 and defines one of the two default handlers. The default handlers are used
 as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}.
@@ -260,5 +250,5 @@
 facing way. So these three macros are provided to wrap these traits to
 simplify referring to the names:
-@IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@, and @IS_RESUMPTION_EXCEPTION@.
+@IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@.
 
 All three take one or two arguments. The first argument is the name of the
@@ -282,22 +272,22 @@
 \CFA provides two kinds of exception handling: termination and resumption.
 These twin operations are the core of \CFA's exception handling mechanism.
-This section covers the general patterns shared by the two operations and
-then goes on to cover the details of each individual operation.
+This section will cover the general patterns shared by the two operations and
+then go on to cover the details each individual operation.
 
 Both operations follow the same set of steps.
-First, a user raises an exception.
-Second, the exception propagates up the stack.
-Third, if a handler is found, the exception is caught and the handler is run.
+Both start with the user preforming a raise on an exception.
+Then the exception propagates up the stack.
+If a handler is found the exception is caught and the handler is run.
 After that control continues at a raise-dependent location.
-Fourth, if a handler is not found, a default handler is run and, if it returns, then control
+If the search fails a default handler is run and, if it returns, then control
 continues after the raise.
 
-%This general description covers what the two kinds have in common.
-The differences in the two operations include how propagation is performed, where execution continues
-after an exception is caught and handled, and which default handler is run.
+This general description covers what the two kinds have in common.
+Differences include how propagation is preformed, where exception continues
+after an exception is caught and handled and which default handler is run.
 
 \subsection{Termination}
 \label{s:Termination}
-Termination handling is the familiar EHM and used in most programming
+Termination handling is the familiar kind and used in most programming
 languages with exception handling.
 It is a dynamic, non-local goto. If the raised exception is matched and
@@ -318,7 +308,7 @@
 @is_termination_exception@ at the call site.
 Through \CFA's trait system, the trait functions are implicitly passed into the
-throw code for use by the EHM.
+throw code and the EHM.
 A new @defaultTerminationHandler@ can be defined in any scope to
-change the throw's behaviour when a handler is not found (see below).
+change the throw's behaviour (see below).
 
 The throw copies the provided exception into managed memory to ensure
@@ -330,8 +320,8 @@
 % How to say propagation starts, its first sub-step is the search.
 Then propagation starts with the search. \CFA uses a ``first match" rule so
-matching is performed with the copied exception as the search key.
-It starts from the raise in the throwing function and proceeds towards the base of the stack,
+matching is preformed with the copied exception as the search continues.
+It starts from the throwing function and proceeds towards base of the stack,
 from callee to caller.
-At each stack frame, a check is made for termination handlers defined by the
+At each stack frame, a check is made for resumption handlers defined by the
 @catch@ clauses of a @try@ statement.
 \begin{cfa}
@@ -345,5 +335,5 @@
 \end{cfa}
 When viewed on its own, a try statement simply executes the statements
-in the \snake{GUARDED_BLOCK}, and when those are finished,
+in \snake{GUARDED_BLOCK} and when those are finished,
 the try statement finishes.
 
@@ -351,10 +341,10 @@
 invoked functions, all the handlers in these statements are included in the
 search path.
-Hence, if a termination exception is raised, these handlers may be matched
+Hence, if a termination exception is raised these handlers may be matched
 against the exception and may handle it.
 
 Exception matching checks the handler in each catch clause in the order
 they appear, top to bottom. If the representation of the raised exception type
-is the same or a descendant of @EXCEPTION_TYPE@$_i$, then @NAME@$_i$
+is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
 (if provided) is
 bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
@@ -362,24 +352,25 @@
 freed and control continues after the try statement.
 
-If no termination handler is found during the search, then the default handler
-(\defaultTerminationHandler) visible at the raise statement is called.
-Through \CFA's trait system the best match at the raise statement is used.
+If no termination handler is found during the search then the default handler
+(\defaultTerminationHandler) visible at the raise statement is run.
+Through \CFA's trait system the best match at the raise statement will be used.
 This function is run and is passed the copied exception.
-If the default handler finishes, control continues after the raise statement.
+If the default handler is run control continues after the raise statement.
 
 There is a global @defaultTerminationHandler@ that is polymorphic over all
 termination exception types.
+Since it is so general a more specific handler can be
+defined and is used for those types, effectively overriding the handler
+for a particular exception type.
 The global default termination handler performs a cancellation
-(see \vref{s:Cancellation} for the justification) on the current stack with the copied exception.
-Since it is so general, a more specific handler is usually
-defined, possibly with a detailed message, and used for specific exception type, effectively overriding the default handler.
+(see \vref{s:Cancellation}) on the current stack with the copied exception.
 
 \subsection{Resumption}
 \label{s:Resumption}
 
-Resumption exception handling is the less familar EHM, but is
+Resumption exception handling is less common than termination but is
 just as old~\cite{Goodenough75} and is simpler in many ways.
 It is a dynamic, non-local function call. If the raised exception is
-matched, a closure is taken from up the stack and executed,
+matched a closure is taken from up the stack and executed,
 after which the raising function continues executing.
 The common uses for resumption exceptions include
@@ -387,5 +378,5 @@
 function once the error is corrected, and
 ignorable events, such as logging where nothing needs to happen and control
-should always continue from the raise point.
+should always continue from the same place.
 
 A resumption raise is started with the @throwResume@ statement:
@@ -401,9 +392,9 @@
 the exception system while handling the exception.
 
-At run-time, no exception copy is made, since
-resumption does not unwind the stack nor otherwise remove values from the
-current scope, so there is no need to manage memory to keep the exception in scope.
-
-Then propagation starts with the search. It starts from the raise in the
+At run-time, no exception copy is made.
+Resumption does not unwind the stack nor otherwise remove values from the
+current scope, so there is no need to manage memory to keep things in scope.
+
+The EHM then begins propagation. The search starts from the raise in the
 resuming function and proceeds towards the base of the stack,
 from callee to caller.
@@ -419,72 +410,45 @@
 }
 \end{cfa}
-% PAB, you say this above.
-% When a try statement is executed, it simply executes the statements in the
-% @GUARDED_BLOCK@ and then finishes.
-% 
-% However, while the guarded statements are being executed, including any
-% invoked functions, all the handlers in these statements are included in the
-% search path.
-% Hence, if a resumption exception is raised, these handlers may be matched
-% against the exception and may handle it.
-% 
-% Exception matching checks the handler in each catch clause in the order
-% they appear, top to bottom. If the representation of the raised exception type
-% is the same or a descendant of @EXCEPTION_TYPE@$_i$, then @NAME@$_i$
-% (if provided) is bound to a pointer to the exception and the statements in
-% @HANDLER_BLOCK@$_i$ are executed.
-% If control reaches the end of the handler, execution continues after the
-% the raise statement that raised the handled exception.
-% 
-% Like termination, if no resumption handler is found during the search,
-% then the default handler (\defaultResumptionHandler) visible at the raise
-% statement is called. It will use the best match at the raise sight according
-% to \CFA's overloading rules. The default handler is
-% passed the exception given to the raise. When the default handler finishes
-% execution continues after the raise statement.
-% 
-% There is a global @defaultResumptionHandler{} is polymorphic over all
-% resumption exceptions and performs a termination throw on the exception.
-% The \defaultTerminationHandler{} can be overridden by providing a new
-% function that is a better match.
-
-The @GUARDED_BLOCK@ and its associated nested guarded statements work the same
-for resumption as for termination, as does exception matching at each
-@catchResume@. Similarly, if no resumption handler is found during the search,
-then the currently visible default handler (\defaultResumptionHandler) is
-called and control continues after the raise statement if it returns. Finally,
-there is also a global @defaultResumptionHandler@, which can be overridden,
-that is polymorphic over all resumption exceptions but performs a termination
-throw on the exception rather than a cancellation.
-
-Throwing the exception in @defaultResumptionHandler@ has the positive effect of
-walking the stack a second time for a recovery handler. Hence, a programmer has
-two chances for help with a problem, fixup or recovery, should either kind of
-handler appear on the stack. However, this dual stack walk leads to following
-apparent anomaly:
-\begin{cfa}
-try {
-	throwResume E;
-} catch (E) {
-	// this handler runs
-}
-\end{cfa}
-because the @catch@ appears to handle a @throwResume@, but a @throwResume@ only
-matches with @catchResume@. The anomaly results because the unmatched
-@catchResuem@, calls @defaultResumptionHandler@, which in turn throws @E@.
-
 % I wonder if there would be some good central place for this.
-Note, termination and resumption handlers may be used together
+Note that termination handlers and resumption handlers may be used together
 in a single try statement, intermixing @catch@ and @catchResume@ freely.
 Each type of handler only interacts with exceptions from the matching
 kind of raise.
+When a try statement is executed, it simply executes the statements in the
+@GUARDED_BLOCK@ and then finishes.
+
+However, while the guarded statements are being executed, including any
+invoked functions, all the handlers in these statements are included in the
+search path.
+Hence, if a resumption exception is raised these handlers may be matched
+against the exception and may handle it.
+
+Exception matching checks the handler in each catch clause in the order
+they appear, top to bottom. If the representation of the raised exception type
+is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
+(if provided) is bound to a pointer to the exception and the statements in
+@HANDLER_BLOCK@$_i$ are executed.
+If control reaches the end of the handler, execution continues after the
+the raise statement that raised the handled exception.
+
+Like termination, if no resumption handler is found during the search,
+the default handler (\defaultResumptionHandler) visible at the raise
+statement is called. It will use the best match at the raise sight according
+to \CFA's overloading rules. The default handler is
+passed the exception given to the raise. When the default handler finishes
+execution continues after the raise statement.
+
+There is a global \defaultResumptionHandler{} is polymorphic over all
+resumption exceptions and preforms a termination throw on the exception.
+The \defaultTerminationHandler{} can be overridden by providing a new
+function that is a better match.
 
 \subsubsection{Resumption Marking}
 \label{s:ResumptionMarking}
 A key difference between resumption and termination is that resumption does
-not unwind the stack. A side effect is that, when a handler is matched
-and run, its try block (the guarded statements) and every try statement
+not unwind the stack. A side effect that is that when a handler is matched
+and run it's try block (the guarded statements) and every try statement
 searched before it are still on the stack. There presence can lead to
-the \emph{recursive resumption problem}.
+the recursive resumption problem.
 
 The recursive resumption problem is any situation where a resumption handler
@@ -500,17 +464,14 @@
 When this code is executed, the guarded @throwResume@ starts a
 search and matches the handler in the @catchResume@ clause. This
-call is placed on the stack above the try-block. Now the second raise in the handler
-searches the same try block, matches, and puts another instance of the
+call is placed on the stack above the try-block. The second raise then
+searches the same try block and puts another instance of the
 same handler on the stack leading to infinite recursion.
 
-While this situation is trivial and easy to avoid, much more complex cycles can
-form with multiple handlers and different exception types.  The key point is
-that the programmer's intuition expects every raise in a handler to start
-searching \emph{below} the @try@ statement, making it difficult to understand
-and fix the problem.
-
-To prevent all of these cases, each try statement is ``marked" from the
-time the exception search reaches it to either when a matching handler
-completes or when the search reaches the base
+While this situation is trivial and easy to avoid, much more complex cycles
+can form with multiple handlers and different exception types.
+
+To prevent all of these cases, a each try statement is ``marked" from the
+time the exception search reaches it to either when the exception is being
+handled completes the matching handler or when the search reaches the base
 of the stack.
 While a try statement is marked, its handlers are never matched, effectively
@@ -524,9 +485,8 @@
 for instance, marking just the handlers that caught the exception,
 would also prevent recursive resumption.
-However, the rule selected mirrors what happens with termination,
-and hence, matches programmer intuition that a raise searches below a try.
-
-In detail, the marked try statements are the ones that would be removed from
-the stack for a termination exception, \ie those on the stack
+However, these rules mirror what happens with termination.
+
+The try statements that are marked are the ones that would be removed from
+the stack if this was a termination exception, that is those on the stack
 between the handler and the raise statement.
 This symmetry applies to the default handler as well, as both kinds of
@@ -562,5 +522,5 @@
 	// Only handle IO failure for f3.
 }
-// Handle a failure relating to f2 further down the stack.
+// Can't handle a failure relating to f2 here.
 \end{cfa}
 In this example the file that experienced the IO error is used to decide
@@ -593,95 +553,38 @@
 
 \subsection{Comparison with Reraising}
-Without conditional catch, the only approach to match in more detail is to reraise
-the exception after it has been caught, if it could not be handled.
-\begin{center}
-\begin{tabular}{l|l}
+A more popular way to allow handlers to match in more detail is to reraise
+the exception after it has been caught, if it could not be handled here.
+On the surface these two features seem interchangeable.
+
+If @throw;@ (no argument) starts a termination reraise,
+which is the same as a raise but reuses the last caught exception,
+then these two statements have the same behaviour:
 \begin{cfa}
 try {
-	do_work_may_throw();
-} catch(excep_t * ex; can_handle(ex)) {
-
-	handle(ex);
-
-
-
+    do_work_may_throw();
+} catch(exception_t * exc ; can_handle(exc)) {
+    handle(exc);
 }
 \end{cfa}
-&
+
 \begin{cfa}
 try {
-	do_work_may_throw();
-} catch(excep_t * ex) { 
-	if (can_handle(ex)) {
-		handle(ex);
-	} else {
-		throw;
-	}
+    do_work_may_throw();
+} catch(exception_t * exc) { 
+    if (can_handle(exc)) {
+        handle(exc);
+    } else {
+        throw;
+    }
 }
 \end{cfa}
-\end{tabular}
-\end{center}
-Notice catch-and-reraise increases complexity by adding additional data and
-code to the exception process. Nevertheless, catch-and-reraise can simulate
-conditional catch straightforwardly, when exceptions are disjoint, \ie no
-inheritance.
-
-However, catch-and-reraise simulation becomes unusable for exception inheritance.
-\begin{flushleft}
-\begin{cfa}[xleftmargin=6pt]
-exception E1;
-exception E2(E1); // inheritance
-\end{cfa}
-\begin{tabular}{l|l}
-\begin{cfa}
-try {
-	... foo(); ... // raise E1/E2
-	... bar(); ... // raise E1/E2
-} catch( E2 e; e.rtn == foo ) {
-	...
-} catch( E1 e; e.rtn == foo ) {
-	...
-} catch( E1 e; e.rtn == bar ) {
-	...
-}
-
-\end{cfa}
-&
-\begin{cfa}
-try {
-	... foo(); ...
-	... bar(); ...
-} catch( E2 e ) {
-	if ( e.rtn == foo ) { ...
-	} else throw; // reraise
-} catch( E1 e ) {
-	if (e.rtn == foo) { ...
-	} else if (e.rtn == bar) { ...
-	else throw; // reraise
-}
-\end{cfa}
-\end{tabular}
-\end{flushleft}
-The derived exception @E2@ must be ordered first in the catch list, otherwise
-the base exception @E1@ catches both exceptions. In the catch-and-reraise code
-(right), the @E2@ handler catches exceptions from both @foo@ and
-@bar@. However, the reraise misses the following catch clause. To fix this
-problem, an enclosing @try@ statement is need to catch @E2@ for @bar@ from the
-reraise, and its handler must duplicate the inner handler code for @bar@. To
-generalize, this fix for any amount of inheritance and complexity of try
-statement requires a technique called \emph{try-block
-splitting}~\cite{Krischer02}, which is not discussed in this thesis. It is
-sufficient to state that conditional catch is more expressive than
-catch-and-reraise in terms of complexity.
-
-\begin{comment}
-That is, they have the same behaviour in isolation.
+That is, they will have the same behaviour in isolation.
 Two things can expose differences between these cases.
 
 One is the existence of multiple handlers on a single try statement.
-A reraise skips all later handlers for a try statement but a conditional
+A reraise skips all later handlers on this try statement but a conditional
 catch does not.
-% Hence, if an earlier handler contains a reraise later handlers are
-% implicitly skipped, with a conditional catch they are not.
+Hence, if an earlier handler contains a reraise later handlers are
+implicitly skipped, with a conditional catch they are not.
 Still, they are equivalently powerful,
 both can be used two mimic the behaviour of the other,
@@ -734,5 +637,4 @@
 %   `exception_ptr current_exception() noexcept;`
 % https://www.python.org/dev/peps/pep-0343/
-\end{comment}
 
 \section{Finally Clauses}
@@ -750,5 +652,5 @@
 The @FINALLY_BLOCK@ is executed when the try statement is removed from the
 stack, including when the @GUARDED_BLOCK@ finishes, any termination handler
-finishes, or during an unwind.
+finishes or during an unwind.
 The only time the block is not executed is if the program is exited before
 the stack is unwound.
@@ -766,14 +668,15 @@
 
 Not all languages with unwinding have finally clauses. Notably \Cpp does
-without it as destructors, and the RAII design pattern, serve a similar role.
-Although destructors and finally clauses can be used for the same cases,
+without it as descructors, and the RAII design pattern, serve a similar role.
+Although destructors and finally clauses can be used in the same cases,
 they have their own strengths, similar to top-level function and lambda
 functions with closures.
-Destructors take more work for their creation, but if there is clean-up code
-that needs to be run every time a type is used, they are much easier
+Destructors take more work for their first use, but if there is clean-up code
+that needs to be run every time a type is used they soon become much easier
 to set-up.
 On the other hand finally clauses capture the local context, so is easy to
 use when the clean-up is not dependent on the type of a variable or requires
 information from multiple variables.
+% To Peter: I think these are the main points you were going for.
 
 \section{Cancellation}
@@ -788,5 +691,5 @@
 raise, this exception is not used in matching only to pass information about
 the cause of the cancellation.
-Finaly, since a cancellation only unwinds and forwards, there is no default handler.
+(This also means matching cannot fail so there is no default handler.)
 
 After @cancel_stack@ is called the exception is copied into the EHM's memory
@@ -799,8 +702,8 @@
 After the main stack is unwound there is a program-level abort. 
 
-The reasons for this semantics in a sequential program is that there is no more code to execute.
-This semantics also applies to concurrent programs, too, even if threads are running.
-That is, if any threads starts a cancellation, it implies all threads terminate.
-Keeping the same behaviour in sequential and concurrent programs is simple.
+There are two reasons for these semantics.
+The first is that it had to do this abort.
+in a sequential program as there is nothing else to notify and the simplicity
+of keeping the same behaviour in sequential and concurrent programs is good.
 Also, even in concurrent programs there may not currently be any other stacks
 and even if other stacks do exist, main has no way to know where they are.
@@ -847,5 +750,5 @@
 caller's context and passes it to the internal report.
 
-A coroutine only knows of two other coroutines, its starter and its last resumer.
+A coroutine knows of two other coroutines, its starter and its last resumer.
 The starter has a much more distant connection, while the last resumer just
 (in terms of coroutine state) called resume on this coroutine, so the message
@@ -855,5 +758,2 @@
 cascade an error across any number of coroutines, cleaning up each in turn,
 until the error is handled or a thread stack is reached.
-
-\PAB{Part of this I do not understand. A cancellation cannot be caught. But you
-talk about handling a cancellation in the last sentence. Which is correct?}
Index: doc/theses/andrew_beach_MMath/intro.tex
===================================================================
--- doc/theses/andrew_beach_MMath/intro.tex	(revision 5438e41a103bfafb23784bfa350297aa8b943faf)
+++ doc/theses/andrew_beach_MMath/intro.tex	(revision f42a6b855873c132f4969475fb95578812619238)
@@ -2,81 +2,42 @@
 
 % The highest level overview of Cforall and EHMs. Get this done right away.
-This thesis covers the design and implementation of the exception handling
+This thesis goes over the design and implementation of the exception handling
 mechanism (EHM) of
 \CFA (pronounced sea-for-all and may be written Cforall or CFA).
-\CFA is a new programming language that extends C, which maintains
+\CFA is a new programming language that extends C, that maintains
 backwards-compatibility while introducing modern programming features.
 Adding exception handling to \CFA gives it new ways to handle errors and
-make large control-flow jumps.
+make other large control-flow jumps.
 
 % Now take a step back and explain what exceptions are generally.
-A language's EHM is a combination of language syntax and run-time
-components that are used to construct, raise, and handle exceptions,
-including all control flow.
-Exceptions are an active mechanism for replacing passive error/return codes and return unions (Go and Rust).
 Exception handling provides dynamic inter-function control flow.
 There are two forms of exception handling covered in this thesis:
 termination, which acts as a multi-level return,
 and resumption, which is a dynamic function call.
-% PAB: Maybe this sentence was suppose to be deleted?
 Termination handling is much more common,
-to the extent that it is often seen as the only form of handling.
-% PAB: I like this sentence better than the next sentence.
-% This separation is uncommon because termination exception handling is so
-% much more common that it is often assumed.
+to the extent that it is often seen
+This seperation is uncommon because termination exception handling is so
+much more common that it is often assumed.
 % WHY: Mention other forms of continuation and \cite{CommonLisp} here?
-
-Exception handling relies on the concept of nested functions to create handlers that deal with exceptions.
+A language's EHM is the combination of language syntax and run-time
+components that are used to construct, raise and handle exceptions,
+including all control flow.
+
+Termination exception handling allows control to return to any previous
+function on the stack directly, skipping any functions between it and the
+current function.
 \begin{center}
-\begin{tabular}[t]{ll}
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt,language=CFA,{moredelim=**[is][\color{red}]{@}{@}}]
-void f( void (*hp)() ) {
-	hp();
-}
-void g( void (*hp)() ) {
-	f( hp );
-}
-void h( int @i@, void (*hp)() ) {
-	void @handler@() { // nested
-		printf( "%d\n", @i@ );
-	}
-	if ( i == 1 ) hp = handler;
-	if ( i > 0 ) h( i - 1, hp );
-	else g( hp );
-}
-h( 2, 0 );
-\end{lstlisting}
-&
-\raisebox{-0.5\totalheight}{\input{handler}}
-\end{tabular}
+\input{callreturn}
 \end{center}
-The nested function @handler@ in the second stack frame is explicitly passed to function @f@.
-When this handler is called in @f@, it uses the parameter @i@ in the second stack frame, which is accessible by an implicit lexical-link pointer.
-Setting @hp@ in @h@ at different points in the recursion, results in invoking a different handler.
-Exception handling extends this idea by eliminating explicit handler passing, and instead, performing a stack search for a handler that matches some criteria (conditional dynamic call), and calls the handler at the top of the stack.
-It is the runtime search $O(N)$ that differentiates an EHM call (raise) from normal dynamic call $O(1)$ via a function or virtual-member pointer.
-
-Termination exception handling searches the stack for a handler, unwinds the stack to the frame containing the matching handler, and calling the handler at the top of the stack.
-\begin{center}
-\input{termination}
-\end{center}
-Note, since the handler can reference variables in @h@, @h@ must remain on the stack for the handler call.
-After the handler returns, control continues after the lexical location of the handler in @h@ (static return)~\cite[p.~108]{Tennent77}.
-Unwinding allows recover to any previous
-function on the stack, skipping any functions between it and the
-function containing the matching handler.
-
-Resumption exception handling searches the stack for a handler, does \emph{not} unwind the stack to the frame containing the matching handler, and calls the handler at the top of the stack.
-\begin{center}
-\input{resumption}
-\end{center}
-After the handler returns, control continues after the resume in @f@ (dynamic return).
-Not unwinding allows fix up of the problem in @f@ by any previous function on the stack, without disrupting the current set of stack frames.
+
+Resumption exception handling seaches the stack for a handler and then calls
+it without adding or removing any other stack frames.
+\todo{Add a diagram showing control flow for resumption.}
 
 Although a powerful feature, exception handling tends to be complex to set up
 and expensive to use
-so it is often limited to unusual or ``exceptional" cases.
-The classic example is error handling, where exceptions are used to
-remove error handling logic from the main execution path, while paying
+so they are often limited to unusual or ``exceptional" cases.
+The classic example of this is error handling, exceptions can be used to
+remove error handling logic from the main execution path and while paying
 most of the cost only when the error actually occurs.
 
@@ -88,17 +49,18 @@
 some of the underlying tools used to implement and express exception handling
 in other languages are absent in \CFA.
-Still the resulting basic syntax resembles that of other languages:
-\begin{lstlisting}[language=CFA,{moredelim=**[is][\color{red}]{@}{@}}]
-@try@ {
+Still the resulting syntax resembles that of other languages:
+\begin{cfa}
+try {
 	...
 	T * object = malloc(request_size);
 	if (!object) {
-		@throw@ OutOfMemory{fixed_allocation, request_size};
+		throw OutOfMemory{fixed_allocation, request_size};
 	}
 	...
-} @catch@ (OutOfMemory * error) {
+} catch (OutOfMemory * error) {
 	...
 }
-\end{lstlisting}
+\end{cfa}
+
 % A note that yes, that was a very fast overview.
 The design and implementation of all of \CFA's EHM's features are
@@ -107,45 +69,46 @@
 
 % The current state of the project and what it contributes.
-The majority of the \CFA EHM is implemented in \CFA, except for a small amount of assembler code.
-In addition,
-a suite of tests and performance benchmarks were created as part of this project.
-The \CFA implementation techniques are generally applicable in other programming
+All of these features have been implemented in \CFA, along with
+a suite of test cases as part of this project.
+The implementation techniques are generally applicable in other programming
 languages and much of the design is as well.
-Some parts of the EHM use features unique to \CFA, and hence,
-are harder to replicate in other programming languages.
+Some parts of the EHM use other features unique to \CFA and these would be
+harder to replicate in other programming languages.
+
 % Talk about other programming languages.
-Three well known programming languages with EHMs, %/exception handling
-C++, Java and Python are examined in the performance work. However, these languages focus on termination
-exceptions, so there is no comparison with resumption.
+Some existing programming languages that include EHMs/exception handling
+include C++, Java and Python. All three examples focus on termination
+exceptions which unwind the stack as part of the
+Exceptions also can replace return codes and return unions.
 
 The contributions of this work are:
 \begin{enumerate}
 \item Designing \CFA's exception handling mechanism, adapting designs from
-other programming languages, and creating new features.
-\item Implementing stack unwinding for the \CFA EHM, including updating
-the \CFA compiler and run-time environment to generate and execute the EHM code.
-\item Designing and implementing a prototype virtual system.
+other programming languages and the creation of new features.
+\item Implementing stack unwinding and the EHM in \CFA, including updating
+the compiler and the run-time environment.
+\item Designed and implemented a prototype virtual system.
 % I think the virtual system and per-call site default handlers are the only
 % "new" features, everything else is a matter of implementation.
-\item Creating tests and performance benchmarks to compare with EHM's in other languages.
 \end{enumerate}
 
-%\todo{I can't figure out a good lead-in to the roadmap.}
-The thesis is organization as follows.
-The next section and parts of \autoref{c:existing} cover existing EHMs.
-New \CFA EHM features are introduced in \autoref{c:features},
-covering their usage and design.
-That is followed by the implementation of these features in
+\todo{I can't figure out a good lead-in to the roadmap.}
+The next section covers the existing state of exceptions.
+The existing state of \CFA is also covered in \autoref{c:existing}.
+The new features are introduced in \autoref{c:features},
+which explains their usage and design.
+That is followed by the implementation of those features in
 \autoref{c:implement}.
-Performance results are presented in \autoref{c:performance}.
-Summing up and possibilities for extending this project are discussed in \autoref{c:future}.
+The performance results are examined in \autoref{c:performance}.
+Possibilities to extend this project are discussed in \autoref{c:future}.
 
 \section{Background}
 \label{s:background}
 
-Exception handling is a well examined area in programming languages,
-with papers on the subject dating back the 70s~\cite{Goodenough75}.
-Early exceptions were often treated as signals, which carried no information
-except their identity. Ada~\cite{Ada} still uses this system.
+Exception handling is not a new concept,
+with papers on the subject dating back 70s.\cite{Goodenough}
+
+Early exceptions were often treated as signals. They carried no information
+except their identity. Ada still uses this system.
 
 The modern flag-ship for termination exceptions is \Cpp,
@@ -153,100 +116,103 @@
 in 1990.
 % https://en.cppreference.com/w/cpp/language/history
-While many EHMs have special exception types,
-\Cpp has the ability to use any type as an exception.
-However, this generality is not particularly useful, and has been pushed aside for classes, with a convention of inheriting from
+\Cpp has the ability to use any value of any type as an exception.
+However that seems to immediately pushed aside for classes inherited from
 \code{C++}{std::exception}.
-While \Cpp has a special catch-all syntax @catch(...)@, there is no way to discriminate its exception type, so nothing can
-be done with the caught value because nothing is known about it.
-Instead the base exception-type \code{C++}{std::exception} is defined with common functionality (such as
-the ability to print a message when the exception is raised but not caught) and all
-exceptions have this functionality.
-Having a root exception-type seems to be the standard now, as the guaranteed functionality is worth
-any lost in flexibility from limiting exceptions types to classes.
-
-Java~\cite{Java} was the next popular language to use exceptions.
-Its exception system largely reflects that of \Cpp, except it requires
-exceptions to be a subtype of \code{Java}{java.lang.Throwable}
+Although there is a special catch-all syntax it does not allow anything to
+be done with the caught value becuase nothing is known about it.
+So instead a base type is defined with some common functionality (such as
+the ability to describe the reason the exception was raised) and all
+exceptions have that functionality.
+This seems to be the standard now, as the garentied functionality is worth
+any lost flexibility from limiting it to a single type.
+
+Java was the next popular language to use exceptions.
+Its exception system largely reflects that of \Cpp, except that requires
+you throw a child type of \code{Java}{java.lang.Throwable}
 and it uses checked exceptions.
-Checked exceptions are part of a function's interface defining all exceptions it or its called functions raise.
-Using this information, it is possible to statically verify if a handler exists for all raised exception, \ie no uncaught exceptions.
-Making exception information explicit, improves clarity and
+Checked exceptions are part of the function interface they are raised from.
+This includes functions they propogate through, until a handler for that
+type of exception is found.
+This makes exception information explicit, which can improve clarity and
 safety, but can slow down programming.
-For example, programming complexity increases when dealing with high-order methods or an overly specified
-throws clause. However some of the issues are more
-programming annoyances, such as writing/updating many exception signatures after adding or remove calls.
-Java programmers have developed multiple programming ``hacks'' to circumvent checked exceptions negating the robustness it is suppose to provide.
-For example, the ``catch-and-ignore" pattern, where the handler is empty because the exception does not appear relevant to the programmer versus
-repairing or recovering from the exception.
-
-%\subsection
-Resumption exceptions are less popular,
-although resumption is as old as termination;
-hence, few
+Some of these, such as dealing with high-order methods or an overly specified
+throws clause, are technical. However some of the issues are much more
+human, in that writing/updating all the exception signatures can be enough
+of a burden people will hack the system to avoid them.
+Including the ``catch-and-ignore" pattern where a catch block is used without
+anything to repair or recover from the exception.
+
+%\subsection
+Resumption exceptions have been much less popular.
+Although resumption has a history as old as termination's, very few
 programming languages have implemented them.
 % http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/
 %   CSL-79-3_Mesa_Language_Manual_Version_5.0.pdf
-Mesa~\cite{Mesa} is one programming languages that did. Experience with Mesa
-is quoted as being one of the reasons resumptions are not
+Mesa is one programming languages that did. Experiance with Mesa
+is quoted as being one of the reasons resumptions were not
 included in the \Cpp standard.
 % https://en.wikipedia.org/wiki/Exception_handling
-As a result, resumption has ignored in main-stream programming languages.
-However, ``what goes around comes around'' and resumption is being revisited now (like user-level threading).
-While rejecting resumption might have been the right decision in the past, there are decades
-of developments in computer science that have changed the situation.
-Some of these developments, such as functional programming's resumption
-equivalent, algebraic effects\cite{Zhang19}, are enjoying significant success.
-A complete reexamination of resumptions is beyond this thesis, but their re-emergence is
-enough to try them in \CFA.
+Since then resumptions have been ignored in the main-stream.
+
+All of this does call into question the use of resumptions, is
+something largely rejected decades ago worth revisiting now?
+Yes, even if it was the right call at the time there have been decades
+of other developments in computer science that have changed the situation
+since then.
+Some of these developments, such as in functional programming's resumption
+equivalent: algebraic effects\cite{Zhang19}, are directly related to
+resumptions as well.
+A complete rexamination of resumptions is beyond a single paper, but it is
+enough to try them again in \CFA.
 % Especially considering how much easier they are to implement than
 % termination exceptions.
 
 %\subsection
-Functional languages tend to use other solutions for their primary EHM,
-but exception-like constructs still appear.
+Functional languages tend to use other solutions for their primary error
+handling mechanism, exception-like constructs still appear.
 Termination appears in error construct, which marks the result of an
-expression as an error; thereafter, the result of any expression that tries to use it is also an
-error, and so on until an appropriate handler is reached.
-Resumption appears in algebraic effects, where a function dispatches its
+expression as an error, the result of any expression that tries to use it as
+an error, and so on until an approprate handler is reached.
+Resumption appears in algebric effects, where a function dispatches its
 side-effects to its caller for handling.
 
 %\subsection
-Some programming languages have moved to a restricted kind of EHM
-called ``panic".
-In Rust~\cite{Rust}, a panic is just a program level abort that may be implemented by
+More recently exceptions seem to be vanishing from newer programming
+languages, replaced by ``panic".
+In Rust a panic is just a program level abort that may be implemented by
 unwinding the stack like in termination exception handling.
 % https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
-In Go~\cite{Go}, a panic is very similar to a termination, except it only supports
+Go's panic through is very similar to a termination except it only supports
 a catch-all by calling \code{Go}{recover()}, simplifying the interface at
-the cost of flexibility.
-
-%\subsection
-While exception handling's most common use cases are in error handling,
-here are other ways to handle errors with comparisons to exceptions.
+the cost of flexability.
+
+%\subsection
+Exception handling's most common use cases are in error handling.
+Here are some other ways to handle errors and comparisons with exceptions.
 \begin{itemize}
 \item\emph{Error Codes}:
-This pattern has a function return an enumeration (or just a set of fixed values) to indicate
-if an error occurred and possibly which error it was.
-
-Error codes mix exceptional and normal values, artificially enlarging the type and/or value range.
-Some languages address this issue by returning multiple values or a tuple, separating the error code from the function result.
-However, the main issue with error codes is forgetting to checking them,
-which leads to an error being quietly and implicitly ignored.
-Some new languages have tools that issue warnings, if the error code is
-discarded to avoid this problem.
-Checking error codes also results in bloating the main execution path, especially if an error is not dealt with locally and has to be cascaded down the call stack to a higher-level function..
-
+This pattern uses an enumeration (or just a set of fixed values) to indicate
+that an error has occured and which error it was.
+
+There are some issues if a function wants to return an error code and another
+value. The main issue is that it can be easy to forget checking the error
+code, which can lead to an error being quitely and implicitly ignored.
+Some new languages have tools that raise warnings if the return value is
+discarded to avoid this.
+It also puts more code on the main execution path.
 \item\emph{Special Return with Global Store}:
-Some functions only return a boolean indicating success or failure
-and store the exact reason for the error in a fixed global location.
-For example, many C routines return non-zero or -1, indicating success or failure,
-and write error details into the C standard variable @errno@.
-
-This approach avoids the multiple results issue encountered with straight error codes
-but otherwise has many (if not more) of the disadvantages.
-For example, everything that uses the global location must agree on all possible errors and global variable are unsafe with concurrency.
-
+A function that encounters an error returns some value indicating that it
+encountered a value but store which error occured in a fixed global location.
+
+Perhaps the C standard @errno@ is the most famous example of this,
+where some standard library functions will return some non-value (often a
+NULL pointer) and set @errno@.
+
+This avoids the multiple results issue encountered with straight error codes
+but otherwise many of the same advantages and disadvantages.
+It does however introduce one other major disadvantage:
+Everything that uses that global location must agree on all possible errors.
 \item\emph{Return Union}:
-This pattern replaces error codes with a tagged union.
+Replaces error codes with a tagged union.
 Success is one tag and the errors are another.
 It is also possible to make each possible error its own tag and carry its own
@@ -254,39 +220,40 @@
 so that one type can be used everywhere in error handling code.
 
-This pattern is very popular in functional or any semi-functional language with
-primitive support for tagged unions (or algebraic data types).
+This pattern is very popular in functional or semi-functional language,
+anything with primitive support for tagged unions (or algebraic data types).
 % We need listing Rust/rust to format code snipits from it.
 % Rust's \code{rust}{Result<T, E>}
-The main advantage is providing for more information about an
-error, other than one of a fix-set of ids.
-While some languages use checked union access to force error-code checking,
-it is still possible to bypass the checking.
-The main disadvantage is again significant error code on the main execution path and cascading through called functions.
-
+
+The main disadvantage is again it puts code on the main execution path.
+This is also the first technique that allows for more information about an
+error, other than one of a fix-set of ids, to be sent.
+They can be missed but some languages can force that they are checked.
+It is also implicitly forced in any languages with checked union access.
 \item\emph{Handler Functions}:
-This pattern implicitly associates functions with errors.
-On error, the function that produced the error implicitly calls another function to
+On error the function that produced the error calls another function to
 handle it.
 The handler function can be provided locally (passed in as an argument,
 either directly as as a field of a structure/object) or globally (a global
 variable).
-C++ uses this approach as its fallback system if exception handling fails, \eg
+
+C++ uses this as its fallback system if exception handling fails.
 \snake{std::terminate_handler} and for a time \snake{std::unexpected_handler}
 
-Handler functions work a lot like resumption exceptions, without the dynamic handler search.
-Therefore, setting setting up the handler can be more complex/expensive, especially if the handle must be passed through multiple function calls, but cheaper to call $O(1)$, and hence,
-are more suited to frequent exceptional situations.
-% The exception being global handlers if they are rarely change as the time
-% in both cases shrinks towards zero.
+Handler functions work a lot like resumption exceptions.
+The difference is they are more expencive to set up but cheaper to use, and
+so are more suited to more fequent errors.
+The exception being global handlers if they are rarely change as the time
+in both cases strinks towards zero.
 \end{itemize}
 
 %\subsection
-Because of their cost, exceptions are rarely used for hot paths of execution.
-Therefore, there is an element of self-fulfilling prophecy for implementation
-techniques to make exceptions cheap to set-up at the cost
-of expensive usage.
-This cost differential is less important in higher-level scripting languages, where use of exceptions for other tasks is more common.
-An iconic example is Python's @StopIteration@ exception that is thrown by
-an iterator to indicate that it is exhausted, especially when combined with Python's heavy
-use of the iterator-based for-loop.
+Because of their cost exceptions are rarely used for hot paths of execution.
+There is an element of self-fulfilling prophocy here as implementation
+techniques have been designed to make exceptions cheap to set-up at the cost
+of making them expencive to use.
+Still, use of exceptions for other tasks is more common in higher-level
+scripting languages.
+An iconic example is Python's StopIteration exception which is thrown by
+an iterator to indicate that it is exausted. Combined with Python's heavy
+use of the iterator based for-loop.
 % https://docs.python.org/3/library/exceptions.html#StopIteration
Index: doc/theses/andrew_beach_MMath/uw-ethesis.tex
===================================================================
--- doc/theses/andrew_beach_MMath/uw-ethesis.tex	(revision 5438e41a103bfafb23784bfa350297aa8b943faf)
+++ doc/theses/andrew_beach_MMath/uw-ethesis.tex	(revision f42a6b855873c132f4969475fb95578812619238)
@@ -210,6 +210,5 @@
 \lstMakeShortInline@
 \lstset{language=CFA,style=cfacommon,basicstyle=\linespread{0.9}\tt}
-% PAB causes problems with inline @=
-%\lstset{moredelim=**[is][\protect\color{red}]{@}{@}}
+\lstset{moredelim=**[is][\protect\color{red}]{@}{@}}
 % Annotations from Peter:
 \newcommand{\PAB}[1]{{\color{blue}PAB: #1}}
@@ -247,5 +246,4 @@
 \input{performance}
 \input{future}
-\input{conclusion}
 
 %----------------------------------------------------------------------