Index: doc/theses/andrew_beach_MMath/future.tex
===================================================================
--- doc/theses/andrew_beach_MMath/future.tex	(revision 553f8abe3b56765e479b425c1828e9d94ef93412)
+++ doc/theses/andrew_beach_MMath/future.tex	(revision 3489ea6b5368a6c4c644cfea5ff5babb268900d5)
@@ -7,5 +7,5 @@
 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
@@ -13,9 +13,11 @@
 hand-crafted assembly statements. These sections must be ported by hand to
 support more hardware architectures, such as the ARM processor.
+\PAB{I think this is a straw-man problem because the hand-coded assembler code
+has to be generated somewhere, and that somewhere is hand-coded.}
 \item
 Due to a type-system problem, the catch clause cannot bind the exception to a
 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@,
@@ -28,8 +30,8 @@
 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
-it in a bad state.
+itself, \eg, a termination exception caught further down the stack or a
+cancellation. There do exist ways to handle this issue, but currently they are not
+even detected and the first unwind is simply dropped, often leaving
+it in a bad state. \Cpp terminates the program in this case, and Java picks the ...
 \item
 Also the exception system did not have a lot of time to be tried and tested.
@@ -41,5 +43,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 +69,7 @@
 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,26 +87,22 @@
 
 \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
 passed on.
 
-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
+However checked exceptions were never seriously considered for this project because
+they have significant usability and reuse trade-offs 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 find a compromise design for checked exceptions in \CFA, possibly using
+polymorphic exception signatures, a form of tunneling\cite{Zhang19}, or
 checked and unchecked raises.
 
@@ -150,8 +148,8 @@
 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 back to the resumption handler.  This approach
+means no special statement is required in the handler to continue after it.
+Currently, \CFA allows a termination exception to be thrown from within any resumption handler so
+there is already a way to partially mimic signal exceptions.
 
 % Maybe talk about the escape; and escape CONTROL_STMT; statements or how
