Index: doc/theses/andrew_beach_MMath/future.tex
===================================================================
--- doc/theses/andrew_beach_MMath/future.tex	(revision c2a9d8836f81405ba3be8ef52e57f0f80c80cdc6)
+++ doc/theses/andrew_beach_MMath/future.tex	(revision 9cd37d9e390510919b7ab3ea6b4d4f2370f7c861)
@@ -2,20 +2,18 @@
 \label{c:future}
 
+The following discussion covers both possible interesting research
+that could follow from this work as long as simple implementation
+improvements.
+
 \section{Language Improvements}
-\todo{Future/Language Improvements seems to have gotten mixed up. It is
-presented as ``waiting on language improvements" but really its more
-non-research based impovements.}
+
 \CFA is a developing programming language. As such, there are partially or
-unimplemented features of the language (including several broken components)
-that I had to workaround while building an exception handling system largely in
-the \CFA language (some C components).  The following are a few of these
-issues, and once implemented/fixed, how they would affect the exception system.
+unimplemented features (including several broken components)
+that I had to workaround while building the EHM largely in
+the \CFA language (some C components). Below are a few of these issues
+and how implementing/fixing them would affect the EHM.
+In addition there are some simple improvements that had no interesting
+research attached to them but would make using the language easier.
 \begin{itemize}
-\item
-The implementation of termination is not portable because it includes
-hand-crafted assembly statements.
-The existing compilers cannot translate that for other platforms and those
-sections must be ported by hand to
-support more hardware architectures, such as the ARM processor.
 \item
 Due to a type-system problem, the catch clause cannot bind the exception to a
@@ -27,18 +25,23 @@
 @return@, \etc. The reason is that current code generation hoists a handler
 into a nested function for convenience (versus assemble-code generation at the
-@try@ statement). Hence, when the handler runs, its code is not in the lexical
-scope of the @try@ statement, where the local control-flow transfers are
-meaningful.
+try statement). Hence, when the handler runs, it can still access local
+variables in the lexical scope of the try statement. Still, it does mean
+that seemingly local control flow is not in fact local and crosses a function
+boundary.
+Making the termination handlers code within the surrounding
+function would remove this limitation.
+% Try blocks are much more difficult to do practically (requires our own
+% assembly) and resumption handlers have some theoretical complexity.
 \item
 There is no detection of colliding unwinds. It is possible for clean-up code
 run during an unwind to trigger another unwind that escapes the clean-up code
 itself; such as a termination exception caught further down the stack or a
-cancellation. There do exist ways to handle this but currently they are not
-even detected and the first unwind will simply be forgotten, often leaving
+cancellation. There do exist ways to handle this case, but currently there is
+no detection and the first unwind will simply be forgotten, often leaving
 it in a bad state.
 \item
-Also the exception system did not have a lot of time to be tried and tested.
-So just letting people use the exception system more will reveal new
-quality of life upgrades that can be made with time.
+Finally, the exception system has not had a lot of programmer testing.
+More time with encouraged usage will reveal new
+quality of life upgrades that can be made.
 \end{itemize}
 
@@ -47,5 +50,5 @@
 project, but was thrust upon it to do exception inheritance; hence, only
 minimal work is done. A draft for a complete virtual system is available but
-it is not finalized.  A future \CFA project is to complete that work and then
+not finalized. A future \CFA project is to complete that work and then
 update the exception system that uses the current version.
 
@@ -53,10 +56,11 @@
 exception traits. The most important one is an assertion to check one virtual
 type is a child of another. This check precisely captures many of the
-correctness requirements.
+current ad-hoc correctness requirements.
 
 The full virtual system might also include other improvement like associated
 types to allow traits to refer to types not listed in their header. This
 feature allows exception traits to not refer to the virtual-table type
-explicitly, removing the need for the current interface macros.
+explicitly, removing the need for the current interface macros,
+such as @EHM_IS_EXCEPTION@.
 
 \section{Additional Raises}
@@ -74,5 +78,5 @@
 Non-local/concurrent raise requires more
 coordination between the concurrency system
-and the exception system. Many of the interesting design decisions centre
+and the exception system. Many of the interesting design decisions center
 around masking, \ie controlling which exceptions may be thrown at a stack. It
 would likely require more of the virtual system and would also effect how
@@ -93,11 +97,11 @@
 Checked exceptions make exceptions part of a function's type by adding an
 exception signature. An exception signature must declare all checked
-exceptions that could propagate from the function (either because they were
-raised inside the function or came from a sub-function). This improves safety
+exceptions that could propagate from the function, either because they were
+raised inside the function or came from a sub-function. This improves safety
 by making sure every checked exception is either handled or consciously
 passed on.
 
 However checked exceptions were never seriously considered for this project
-because they have significant trade-offs in usablity and code reuse in
+because they have significant trade-offs in usability and code reuse in
 exchange for the increased safety.
 These trade-offs are most problematic when trying to pass exceptions through
@@ -129,6 +133,6 @@
 not support a successful-exiting stack-search without doing an unwind.
 Workarounds are possible but awkward. Ideally an extension to libunwind could
-be made, but that would either require separate maintenance or gain enough
-support to have it folded into the standard.
+be made, but that would either require separate maintenance or gaining enough
+support to have it folded into the official library itself.
 
 Also new techniques to skip previously searched parts of the stack need to be
@@ -158,5 +162,5 @@
 to leave the handler.
 Currently, mimicking this behaviour in \CFA is possible by throwing a
-termination inside a resumption handler.
+termination exception inside a resumption handler.
 
 % Maybe talk about the escape; and escape CONTROL_STMT; statements or how
