Index: doc/theses/andrew_beach_MMath/intro.tex
===================================================================
--- doc/theses/andrew_beach_MMath/intro.tex	(revision d2278e9bd5880b8fddae1c58dd1056df8e64d834)
+++ doc/theses/andrew_beach_MMath/intro.tex	(revision 00da199562ec3c4b8d4fbd5ae8a205c18cb892ce)
@@ -107,13 +107,28 @@
 
 Exception handling is not a new concept,
-with papers on the subject dating back 70s.
-
-Their were popularised by \Cpp,
+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,
 which added them in its first major wave of non-object-orientated features
 in 1990.
 % https://en.cppreference.com/w/cpp/language/history
-
-Java was the next popular language to use exceptions. It is also the most
-popular language with checked exceptions.
+\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}.
+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 the function interface they are raised from.
 This includes functions they propogate through, until a handler for that
@@ -131,35 +146,44 @@
 Resumption exceptions have been much less popular.
 Although resumption has a history as old as termination's, very few
-programming languages have implement them.
+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 is one programming languages that did and experiance with that
-languages is quoted as being one of the reasons resumptions were 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
-\todo{A comment about why we did include them when they are so unpopular
-might be approprate.}
-
-%\subsection
-Functional languages, tend to use solutions like the return union, but some
-exception-like constructs still appear.
-
-For instance Haskell's built in error mechanism can make the result of any
-expression, including function calls. Any expression that examines an
-error value will in-turn produce an error. This continues until the main
-function produces an error or until it is handled by one of the catch
-functions.
+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 error
+handling mechanism, exception-like constructs still appear.
+Termination appears in error construct, which marks the result of an
+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
 More recently exceptions seem to be vanishing from newer programming
-languages.
-Rust and Go reduce this feature to panics.
-Panicing is somewhere between a termination exception and a program abort.
-Notably in Rust a panic can trigger either, a panic may unwind the stack or
-simply kill the process.
+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
-Go's panic is much more similar to a termination exception but there is
-only a catch-all function with \code{Go}{recover()}.
-So exceptions still are appearing, just in reduced forms.
+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 flexability.
 
 %\subsection
