Index: doc/theses/andrew_beach_MMath/features.tex
===================================================================
--- doc/theses/andrew_beach_MMath/features.tex	(revision c1136c56605f040aed4d11ff33e746bc1cefb3fd)
+++ doc/theses/andrew_beach_MMath/features.tex	(revision 2d8a770eb55adae00a48d7d9da1b194d16f41862)
@@ -101,5 +101,5 @@
 between different sub-hierarchies.
 This design is used in \CFA even though it is not a object-orientated
-language using different tools to create the hierarchy.
+language; so different tools are used to create the hierarchy.
 
 % Could I cite the rational for the Python IO exception rework?
@@ -123,9 +123,16 @@
 \section{Virtuals}
 Virtual types and casts are not part of \CFA's EHM nor are they required for
-any EHM. But \CFA uses a hierarchial system of exceptions and this feature
-is leveraged to create that.
-
-% Maybe talk about why the virtual system is so minimal.
-% Created for but not a part of the exception system.
+any EHM.
+However the \CFA uses a hierarchy built with the virtual system as the basis
+for exceptions and exception matching.
+
+The virtual system would have ideally been part of \CFA before the work
+on exception handling began, but unfortunately it was not.
+Because of this only the features and framework needed for the EHM were
+designed and implemented. Other features were considered to ensure that
+the structure could accomidate other desirable features but they were not
+implemented.
+The rest of this section will only discuss the finalized portion of the
+virtual system.
 
 The virtual system supports multiple ``trees" of types. Each tree is
@@ -175,5 +182,5 @@
 While much of the virtual infrastructure is created, it is currently only used
 internally for exception handling. The only user-level feature is the virtual
-cast, which is the same as the \Cpp \lstinline[language=C++]|dynamic_cast|.
+cast, which is the same as the \Cpp \codeCpp{dynamic_cast}.
 \label{p:VirtualCast}
 \begin{cfa}
@@ -197,23 +204,15 @@
 \begin{cfa}
 trait is_exception(exceptT &, virtualT &) {
-	virtualT const & get_exception_vtable(exceptT *);
+	// Numerous imaginary assertions.
 };
 \end{cfa}
 The trait is defined over two types, the exception type and the virtual table
-type. This should be one-to-one: each exception type has only one virtual
-table type and vice versa. The only assertion in the trait is
-@get_exception_vtable@, which takes a pointer of the exception type and
-returns a reference to the virtual table type instance.
-
-% TODO: This section, and all references to get_exception_vtable, are
-% out-of-data. Perhaps wait until the update is finished before rewriting it.
-The function @get_exception_vtable@ is actually a constant function.
-Regardless of the value passed in (including the null pointer) it should
-return a reference to the virtual table instance for that type.
-The reason it is a function instead of a constant is that it make type
-annotations easier to write as you can use the exception type instead of the
-virtual table type; which usually has a mangled name.
-% Also \CFA's trait system handles functions better than constants and doing
-% it this way reduce the amount of boiler plate we need.
+type. Each exception type should have but a single virtual table type.
+Now there are no actual assertions in this trait because the trait system
+actually can't express them (adding such assertions would be part of
+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 decendent of @exception_t@ (the base exception type)
+and note its virtual table type.
 
 % I did have a note about how it is the programmer's responsibility to make
@@ -473,5 +472,5 @@
 The symmetry between resumption termination is why this pattern was picked.
 Other patterns, such as marking just the handlers that caught, also work but
-lack the symmetry means there are less rules to remember.
+lack the symmetry means there are more rules to remember.
 
 \section{Conditional Catch}
@@ -558,6 +557,6 @@
 \end{cfa}
 If there are further handlers after this handler only the first version will
-check them. If multiple handlers on a single try block could handle the same
-exception the translations get more complex but they are equivilantly
+check them. If multiple handlers on a single try block that could handle the
+same exception the translations get more complex but they are equivilantly
 powerful.
 
@@ -634,6 +633,6 @@
 and the current stack is
 unwound. After that it depends one which stack is being cancelled.
-\begin{description}
-\item[Main Stack:]
+
+\paragraph{Main Stack}
 The main stack is the one used by the program main at the start of execution,
 and is the only stack in a sequential program.
@@ -646,5 +645,5 @@
 to, so it would have be explicitly managed.
 
-\item[Thread Stack:]
+\paragraph{Thread Stack}
 A thread stack is created for a \CFA @thread@ object or object that satisfies
 the @is_thread@ trait.
@@ -672,5 +671,5 @@
 Also you can always add an explicit join if that is the desired behaviour.
 
-\item[Coroutine Stack:]
+\paragraph{Coroutine Stack}
 A coroutine stack is created for a @coroutine@ object or object that
 satisfies the @is_coroutine@ trait.
@@ -686,3 +685,2 @@
 (in terms of coroutine state) called resume on this coroutine, so the message
 is passed to the latter.
-\end{description}