Index: doc/theses/andrew_beach_MMath/future.tex
===================================================================
--- doc/theses/andrew_beach_MMath/future.tex	(revision 6071efc365ffe6b254040fac5d9263f8ea0a0cb8)
+++ doc/theses/andrew_beach_MMath/future.tex	(revision edebbf7457a2b240c384c9ad94a2aaea86869e2d)
@@ -3,13 +3,18 @@
 
 \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 this would affect the exception system.
+issues, and once implemented/fixed, how they would affect the exception system.
 \begin{itemize}
 \item
 The implementation of termination is not portable because it includes
-hand-crafted assembly statements. These sections must be ported by hand to
+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
@@ -17,5 +22,5 @@
 reference instead of a pointer. Since \CFA has a very general reference
 capability, programmers will want to use it. Once fixed, this capability should
-result in little or no change in the exception system.
+result in little or no change in the exception system but simplify usage.
 \item
 Termination handlers cannot use local control-flow transfers, \eg by @break@,
@@ -41,5 +46,5 @@
 The virtual system should be completed. It was not supposed to be part of this
 project, but was thrust upon it to do exception inheritance; hence, only
-minimal work was done. A draft for a complete virtual system is available but
+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
 update the exception system that uses the current version.
@@ -67,7 +72,8 @@
 bad software engineering.
 
-Non-local/concurrent requires more coordination between the concurrency system
+Non-local/concurrent raise requires more
+coordination between the concurrency system
 and the exception system. Many of the interesting design decisions centre
-around masking (controlling which exceptions may be thrown at a stack). It
+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
 default handlers are set.
@@ -85,7 +91,7 @@
 
 \section{Checked Exceptions}
-Checked exceptions make exceptions part of a function's type by adding the
+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 propogate from the function (either because they were
+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
@@ -93,18 +99,15 @@
 
 However checked exceptions were never seriously considered for this project
-for two reasons. The first is due to time constraints, even copying an
-existing checked exception system would be pushing the remaining time and
-trying to address the second problem would take even longer. The second
-problem is that checked exceptions have some real usability trade-offs in
+because they have significant trade-offs in usablity and code reuse in
 exchange for the increased safety.
-
 These trade-offs are most problematic when trying to pass exceptions through
 higher-order functions from the functions the user passed into the
 higher-order function. There are no well known solutions to this problem
-that were statifactory for \CFA (which carries some of C's flexability
-over safety design) so one would have to be researched and developed.
+that were satisfactory for \CFA (which carries some of C's flexibility
+over safety design) so additional research is needed.
 
-Follow-up work might add checked exceptions to \CFA, possibly using
-polymorphic exception signatures, a form of tunneling\cite{Zhang19} or
+Follow-up work might add some form of checked exceptions to \CFA,
+possibly using polymorphic exception signatures,
+a form of tunneling\cite{Zhang19} or
 checked and unchecked raises.
 
@@ -150,8 +153,10 @@
 For instance, resumption could be extended to cover this use by allowing local
 control flow out of it. This approach would require an unwind as part of the
-transition as there are stack frames that have to be removed.  This approach
-means there is no notify raise, but because \CFA does not have exception
-signatures, a termination can be thrown from within any resumption handler so
-there is already a way to do mimic this in existing \CFA.
+transition as there are stack frames that have to be removed between where
+the resumption handler is installed and where it is defined.
+This approach would not require, but might benefit from, a special statement
+to leave the handler.
+Currently, mimicking this behaviour in \CFA is possible by throwing a
+termination inside a resumption handler.
 
 % Maybe talk about the escape; and escape CONTROL_STMT; statements or how