Changeset f99f5ba

.gitignore

rcd70477	rf99f5ba
79	79	# generated by npm
80	80	package-lock.json
	81
	82	# generated by benchmark
	83	benchmark/Cargo.toml

doc/LaTeXmacros/common.tex

-                      rcd70477
+                      rf99f5ba
 %% Created On       : Sat Apr  9 10:06:17 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Mon Oct  5 09:34:46 2020
 %% Update Count     : 464
+%% Last Modified On : Thu Jan 28 19:01:57 2021
+%% Update Count     : 494
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \setlist[enumerate]{listparindent=\parindent}% global
 \setlist[enumerate,2]{leftmargin=\parindent,labelsep=*,align=parleft,label=\alph*.}% local
 \setlist[description]{itemsep=0pt,listparindent=\parindent,leftmargin=\parindent,labelsep=1.5ex}
+\setlist[description]{topsep=0.5ex,itemsep=0pt,listparindent=\parindent,leftmargin=\parindent,labelsep=1.5ex}
 % Names used in the document.
 …
 \newcommand{\italic}[1]{\emph{\hyperpage{#1}}}
 \newcommand{\Definition}[1]{\textbf{\hyperpage{#1}}}
 \newcommand{\see}[1]{\emph{see}~#1}
+\newcommand{\see}[1]{(see #1)}
 % Define some commands that produce formatted index entries suitable for cross-references.
 …
 \usepackage{listings}                                                                   % format program code
 \usepackage{lstlang}
+\usepackage{calc}                                                                               % latex arithmetic
 \makeatletter
 \newcommand{\LstBasicStyle}[1]{{\lst@basicstyle{#1}}}
 \newcommand{\LstKeywordStyle}[1]{{\lst@basicstyle{\lst@keywordstyle{#1}}}}
 …
 showlines=true,                                                 % show blank lines at end of code
 aboveskip=4pt,                                                  % spacing above/below code block
+belowskip=3pt,
+belowskip=-2pt,
+numberstyle=\footnotesize\sf,                   % numbering style
 % replace/adjust listing characters that look bad in sanserif
 literate={-}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.75ex}{0.1ex}}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1
 …
 language=CFA,
 escapechar=\$,                                                  % LaTeX escape in CFA code
+mathescape=false,                                               % LaTeX math escape in CFA code $...$
 moredelim=**[is][\color{red}]{@}{@},    % red highlighting @...@
 }% lstset

doc/bibliography/pl.bib

-                      rcd70477
+                      rf99f5ba
+}
 @article{Delisle19,
+@article{Delisle20,
     keywords    = {concurrency, Cforall},
     contributer = {pabuhr@plg},
     author      = {Thierry Delisle and Peter A. Buhr},
     title       = {Advanced Control-flow and Concurrency in \textsf{C}$\mathbf{\forall}$},
     year        = 2019,
+    year        = 2020,
     journal     = spe,
+    pages       = {1-33},
+    note        = {submitted},
+    pages       = {1-38},
+    note        = {\href{https://doi-org.proxy.lib.uwaterloo.ca/10.1002/spe.2925}{https://\-doi-org.proxy.lib.uwaterloo.ca/\-10.1002/\-spe.2925}},
+    note        = {},
+}

doc/theses/andrew_beach_MMath/.gitignore

rcd70477	rf99f5ba
3	3
4	4	# Final Files:
5		~~thesis~~.pdf
	5	*.pdf
6	6
7	7	# The Makefile here is not generated.

doc/theses/andrew_beach_MMath/existing.tex

-                      rcd70477
+                      rf99f5ba
+\chapter{\CFA Existing Features}
+\CFA (C-for-all)~\cite{Cforall} is an open-source project extending ISO C with modern safety and productivity features, while still ensuring backwards compatibility with C and its programmers.
+\CFA is designed to have an orthogonal feature-set based closely on the C programming paradigm (non-object-oriented) and these features can be added incrementally to an existing C code-base allowing programmers to learn \CFA on an as-needed basis.
+\section{Overloading and extern}
+Cforall has overloading, allowing multiple definitions of the same name to
+be defined.~\cite{Moss18}
+This also adds name mangling so that the assembly symbols are unique for
+different overloads. For compatability with names in C there is also a
+syntax to diable the name mangling. These unmangled names cannot be overloaded
+but act as the interface between C and \CFA code.
+The syntax for disabling mangling is:
+\begin{cfa}
+extern "C" {
+    ...
+}
+\end{cfa}
+To re-enable mangling once it is disabled the syntax is:
+\begin{cfa}
+extern "Cforall" {
+    ...
+}
+\end{cfa}
+Both should occur at the declaration level and effect all the declarations
+in @...@. Neither care about the state of mangling when they begin
+and will return to that state after the group is finished. So re-enabling
+is only used to nest areas of mangled and unmangled declarations.
+\section{References}
+\CFA adds references to C. These are auto-dereferencing pointers and use the
+same syntax as pointers except they use ampersand (@&@) instead of
+the asterisk (@*@). They can also be constaint or mutable, if they
+are mutable they may be assigned to by using the address-of operator
+(@&@) which converts them into a pointer.
+\chapter{\texorpdfstring{\CFA Existing Features}{Cforall Existing Features}}
+\CFA (C-for-all)~\cite{Cforall} is an open-source project extending ISO C with
+modern safety and productivity features, while still ensuring backwards
+compatibility with C and its programmers.  \CFA is designed to have an
+orthogonal feature-set based closely on the C programming paradigm
+(non-object-oriented) and these features can be added incrementally to an
+existing C code-base allowing programmers to learn \CFA on an as-needed basis.
+Only those \CFA features pertinent to this thesis are discussed.  Many of the
+\CFA syntactic and semantic features used in the thesis should be fairly
+obvious to the reader.
+\section{\texorpdfstring{Overloading and \lstinline|extern|}{Overloading and extern}}
+\CFA has extensive overloading, allowing multiple definitions of the same name
+to be defined.~\cite{Moss18}
+\begin{cfa}
+char i; int i; double i;                        $\C[3.75in]{// variable overload}$
+int f(); double f();                            $\C{// return overload}$
+void g( int ); void g( double );        $\C{// parameter overload}\CRT$
+\end{cfa}
+This feature requires name mangling so the assembly symbols are unique for
+different overloads. For compatibility with names in C, there is also a syntax
+to disable name mangling. These unmangled names cannot be overloaded but act as
+the interface between C and \CFA code.  The syntax for disabling/enabling
+mangling is:
+\begin{cfa}
+// name mangling
+int i; // _X1ii_1
+@extern "C"@ {  // no name mangling
+        int j; // j
+        @extern "Cforall"@ {  // name mangling
+                int k; // _X1ki_1
+        }
+        // no name mangling
+}
+// name mangling
+\end{cfa}
+Both forms of @extern@ affect all the declarations within their nested lexical
+scope and transition back to the previous mangling state when the lexical scope
+ends.
+\section{Reference Type}
+\CFA adds a rebindable reference type to C, but more expressive than the \CC
+reference.  Multi-level references are allowed and act like auto-dereferenced
+pointers using the ampersand (@&@) instead of the pointer asterisk (@*@). \CFA
+references may also be mutable or non-mutable. If mutable, a reference variable
+may be assigned to using the address-of operator (@&@), which converts the
+reference to a pointer.
+\begin{cfa}
+int i, j;
+int @&@ ri = i, @&&@ rri = ri;
+rri = 3;  // auto-dereference assign to i
+@&@ri = @&@j; // rebindable
+ri = 5;   // assign to j
+\end{cfa}
 \section{Constructors and Destructors}
 Both constructors and destructors are operators, which means they are just
+functions with special names. The special names are used to define them and
+may be used to call the functions expicately. The \CFA special names are
+constructed by taking the tokens in the operators and putting @?@ where
+the arguments would go. So multiplication is @?*?@ while dereference
+is @*?@. This also make it easy to tell the difference between
+pre-fix operations (such as @++?@) and post-fix operations
+(@?++@).
+The special name for contructors is @?{}@, which comes from the
+initialization syntax in C. The special name for destructors is
+@^{}@. % I don't like the \^{} symbol but $^\wedge$ isn't better.
+Any time a type T goes out of scope the destructor matching
+@void ^?{}(T &);@ is called. In theory this is also true of
+primitive types such as @int@, but in practice those are no-ops and
+are usually omitted for optimization.
+functions with special operator names rather than type names in \CC. The
+special operator names may be used to call the functions explicitly (not
+allowed in \CC for constructors).
+In general, operator names in \CFA are constructed by bracketing an operator
+token with @?@, which indicates where the arguments. For example, infixed
+multiplication is @?*?@ while prefix dereference is @*?@. This syntax make it
+easy to tell the difference between prefix operations (such as @++?@) and
+post-fix operations (@?++@).
+The special name for a constructor is @?{}@, which comes from the
+initialization syntax in C. The special name for a destructor is @^{}@, where
+the @^@ has no special meaning.
+% I don't like the \^{} symbol but $^\wedge$ isn't better.
+\begin{cfa}
+struct T { ... };
+void ?@{}@(@T &@ this, ...) { ... }  // constructor
+void ?@^{}@(@T &@ this, ...) { ... } // destructor
+{
+        T s = @{@ ... @}@;  // same constructor/initialization braces
+} // destructor call automatically generated
+\end{cfa}
+The first parameter is a reference parameter to the type for the
+constructor/destructor. Destructors may have multiple parameters.  The compiler
+implicitly matches an overloaded constructor @void ^?{}(T &, ...);@ to an
+object declaration with associated initialization, and generates a construction
+call after the object is allocated. When an object goes out of scope, the
+matching overloaded destructor @void ^?{}(T &);@ is called.  Without explicit
+definition, \CFA creates a default and copy constructor, destructor and
+assignment (like \CC). It is possible to define constructors/destructors for
+basic and existing types.
 \section{Polymorphism}
+\CFA uses polymorphism to create functions and types that are defined over
+different types. \CFA polymorphic declarations serve the same role as \CC
+templates or Java generics.
+Polymorphic declaractions start with a forall clause that goes before the
+standard (monomorphic) declaration. These declarations have the same syntax
+except that you may use the names introduced by the forall clause in them.
+Forall clauses are written @forall( ... )@ where @...@ becomes
+the list of polymorphic variables (local type names) and assertions, which
+repersent required operations on those types.
+\begin{cfa}
+forall(dtype T | { void do_once(T &); })
+void do_twice(T & value) {
+    do_once(value);
+    do_once(value);
+}
+\end{cfa}
+A polymorphic function can be used in the same way normal functions are.
+The polymorphics variables are filled in with concrete types and the
+assertions are checked. An assertion checked by seeing if that name of that
+type (with all the variables replaced with the concrete types) is defined at
+the the call site.
+As an example, even if no function named @do_once@ is not defined
+near the definition of @do_twice@ the following code will work.
+\begin{cfa}
+\CFA uses parametric polymorphism to create functions and types that are
+defined over multiple types. \CFA polymorphic declarations serve the same role
+as \CC templates or Java generics. The ``parametric'' means the polymorphism is
+accomplished by passing argument operations to associate \emph{parameters} at
+the call site, and these parameters are used in the function to differentiate
+among the types the function operates on.
+Polymorphic declarations start with a universal @forall@ clause that goes
+before the standard (monomorphic) declaration. These declarations have the same
+syntax except they may use the universal type names introduced by the @forall@
+clause.  For example, the following is a polymorphic identity function that
+works on any type @T@:
+\begin{cfa}
+@forall( T )@ @T@ identity( @T@ val ) { return val; }
+int forty_two = identity( 42 ); // T bound to int, forty_two == 42
+\end{cfa}
+To allow a polymorphic function to be separately compiled, the type @T@ must be
+constrained by the operations used on @T@ in the function body. The @forall@
+clauses is augmented with a list of polymorphic variables (local type names)
+and assertions (constraints), which represent the required operations on those
+types used in a function, \eg:
+\begin{cfa}
+forall( T @| { void do_once(T); }@) // assertion
+void do_twice(T value) {
+        do_once(value);
+        do_once(value);
+}
+void do_once(int i) { ... }  // provide assertion
+int i;
+do_twice(i); // implicitly pass assertion do_once to do_twice
+\end{cfa}
+Any object with a type fulfilling the assertion may be passed as an argument to
+a @do_twice@ call.
+A polymorphic function can be used in the same way as a normal function.  The
+polymorphic variables are filled in with concrete types and the assertions are
+checked. An assertion is checked by verifying each assertion operation (with
+all the variables replaced with the concrete types from the arguments) is
+defined at a call site.
+Note, a function named @do_once@ is not required in the scope of @do_twice@ to
+compile it, unlike \CC template expansion. Furthermore, call-site inferencing
+allows local replacement of the most specific parametric functions needs for a
+call.
+\begin{cfa}
+void do_once(double y) { ... } // global
 int quadruple(int x) {
+    void do_once(int & y) {
+        y = y * 2;
+    }
+    do_twice(x);
+    return x;
+}
+\end{cfa}
+This is not the recommended way to implement a quadruple function but it
+does work. The complier will deduce that @do_twice@'s T is an
+integer from the argument. It will then look for a definition matching the
+assertion which is the @do_once@ defined within the function. That
+function will be passed in as a function pointer to @do_twice@ and
+called within it.
+To avoid typing out long lists of assertions again and again there are also
+traits which collect assertions into convenent packages that can then be used
+in assertion lists instead of all of their components.
+\begin{cfa}
+trait done_once(dtype T) {
+    void do_once(T &);
+}
+\end{cfa}
+After this the forall list in the previous example could instead be written
+with the trait instead of the assertion itself.
+\begin{cfa}
+forall(dtype T | done_once(T))
+\end{cfa}
+Traits can have arbitrary number of assertions in them and are usually used to
+create short hands for, and give descriptive names to, commond groupings of
+assertions.
+Polymorphic structures and unions may also be defined by putting a forall
+clause before the declaration. The type variables work the same way except
+are now used in field declaractions instead of parameters and local variables.
+        void do_once(int y) { y = y * 2; } // local
+        do_twice(x); // using local "do_once"
+        return x;
+}
+\end{cfa}
+Specifically, the complier deduces that @do_twice@'s T is an integer from the
+argument @x@. It then looks for the most specific definition matching the
+assertion, which is the nested integral @do_once@ defined within the
+function. The matched assertion function is then passed as a function pointer
+to @do_twice@ and called within it.
+To avoid typing long lists of assertions, constraints can be collect into
+convenient packages called a @trait@, which can then be used in an assertion
+instead of the individual constraints.
+\begin{cfa}
+trait done_once(T) {
+        void do_once(T);
+}
+\end{cfa}
+and the @forall@ list in the previous example is replaced with the trait.
+\begin{cfa}
+forall(dtype T | @done_once(T)@)
+\end{cfa}
+In general, a trait can contain an arbitrary number of assertions, both
+functions and variables, and are usually used to create a shorthand for, and
+give descriptive names to, common groupings of assertions describing a certain
+functionality, like @sumable@, @listable@, \etc.
+Polymorphic structures and unions are defined by qualifying the aggregate type
+with @forall@. The type variables work the same except they are used in field
+declarations instead of parameters, returns, and local variable declarations.
 \begin{cfa}
 forall(dtype T)
 struct node {
+    node(T) * next;
+    T * data;
+}
+\end{cfa}
+The @node(T)@ is a use of a polymorphic structure. Polymorphic types
+must be provided their polymorphic parameters.
+There are many other features of polymorphism that have not given here but
+these are the ones used by the exception system.
+        node(T) * next;  // generic linked node
+        T * data;
+}
+\end{cfa}
+The generic type @node(T)@ is an example of a polymorphic-type usage.  Like \CC
+templates usage, a polymorphic-type usage must specify a type parameter.
+There are many other polymorphism features in \CFA but these are the ones used
+by the exception system.
 \section{Concurrency}
+\CFA has a number of concurrency features, @thread@s,
+@monitor@s and @mutex@ parameters, @coroutine@s and
+@generator@s. The two features that interact with the exception system
+are @thread@s and @coroutine@s; they and their supporting
+constructs will be described here.
+\subsection{Coroutines}
+Coroutines are routines that do not have to finish execution to hand control
+back to their caller, instead they may suspend their execution at any time
+and resume it later.
+Coroutines are not true concurrency but share some similarities and many of
+the same underpinnings and so are included as part of the \CFA threading
+library.
+In \CFA coroutines are created using the @coroutine@ keyword which
+works just like @struct@ except that the created structure will be
+modified by the compiler to satify the @is_coroutine@ trait.
+These structures act as the interface between callers and the coroutine,
+the fields are used to pass information in and out. Here is a simple example
+where the single field is used to pass the next number in a sequence out.
+\CFA has a number of concurrency features: @thread@, @monitor@, @mutex@
+parameters, @coroutine@ and @generator@. The two features that interact with
+the exception system are @thread@ and @coroutine@; they and their supporting
+constructs are described here.
+\subsection{Coroutine}
+A coroutine is a type with associated functions, where the functions are not
+required to finish execution when control is handed back to the caller. Instead
+they may suspend execution at any time and be resumed later at the point of
+last suspension. (Generators are stackless and coroutines are stackful.) These
+types are not concurrent but share some similarities along with common
+underpinnings, so they are combined with the \CFA threading library. Further
+discussion in this section only refers to the coroutine because generators are
+similar.
+In \CFA, a coroutine is created using the @coroutine@ keyword, which is an
+aggregate type like @struct,@ except the structure is implicitly modified by
+the compiler to satisfy the @is_coroutine@ trait; hence, a coroutine is
+restricted by the type system to types that provide this special trait.  The
+coroutine structure acts as the interface between callers and the coroutine,
+and its fields are used to pass information in and out of coroutine interface
+functions.
+Here is a simple example where a single field is used to pass (communicate) the
+next number in a sequence.
 \begin{cfa}
 coroutine CountUp {
+    unsigned int next;
+}
+\end{cfa}
+The routine part of the coroutine is a main function for the coroutine. It
+takes a reference to a coroutine object and returns nothing. In this function,
+and any functions called by this function, the suspend statement may be used
+to return execution to the coroutine's caller. When control returns to the
+function it continue from that same suspend statement instead of at the top
+of the function.
+\begin{cfa}
+void main(CountUp & this) {
+    unsigned int next = 0;
+    while (true) {
+        this.next = next;
+        suspend;
+        next = next + 1;
+    }
+}
+\end{cfa}
+Control is passed to the coroutine with the resume function. This includes the
+first time when the coroutine is starting up. The resume function takes a
+reference to the coroutine structure and returns the same reference. The
+return value is for easy access to communication variables. For example the
+next value from a count-up can be generated and collected in a single
+expression: @resume(count).next@.
+        unsigned int next; // communication variable
+}
+CountUp countup;
+\end{cfa}
+Each coroutine has @main@ function, which takes a reference to a coroutine
+object and returns @void@.
+\begin{cfa}[numbers=left]
+void main(@CountUp & this@) { // argument matches trait is_coroutine
+        unsigned int up = 0;  // retained between calls
+        while (true) {
+                next = up; // make "up" available outside function
+                @suspend;@$\label{suspend}$
+                up += 1;
+        }
+}
+\end{cfa}
+In this function, or functions called by this function (helper functions), the
+@suspend@ statement is used to return execution to the coroutine's caller
+without terminating the coroutine.
+A coroutine is resumed by calling the @resume@ function, \eg @resume(countup)@.
+The first resume calls the @main@ function at the top. Thereafter, resume calls
+continue a coroutine in the last suspended function after the @suspend@
+statement, in this case @main@ line~\ref{suspend}.  The @resume@ function takes
+a reference to the coroutine structure and returns the same reference. The
+return value allows easy access to communication variables defined in the
+coroutine object. For example, the @next@ value for coroutine object @countup@
+is both generated and collected in the single expression:
+@resume(countup).next@.
 \subsection{Monitors and Mutex}
+True concurrency does not garrenty ordering. To get some of that ordering back
+\CFA uses monitors and mutex (mutual exclution) parameters. A monitor is
+another special declaration that contains a lock and is compatable with mutex
+parameters.
+Function parameters can have the @mutex@ qualifiers on reference
+arguments, for example @void example(a_monitor & mutex arg);@. When the
+function is called it will acquire the lock on all of the mutex parameters.
+This means that all functions that mutex on a type are part of a critical
+section and only one will ever run at a time.
+Concurrency does not guarantee ordering; without ordering results are
+non-deterministic. To claw back ordering, \CFA uses monitors and @mutex@
+(mutual exclusion) parameters. A monitor is another kind of aggregate, where
+the compiler implicitly inserts a lock and instances are compatible with
+@mutex@ parameters.
+A function that requires deterministic (ordered) execution, acquires mutual
+exclusion on a monitor object by qualifying an object reference parameter with
+@mutex@.
+\begin{cfa}
+void example(MonitorA & @mutex@ argA, MonitorB & @mutex@ argB);
+\end{cfa}
+When the function is called, it implicitly acquires the monitor lock for all of
+the mutex parameters without deadlock.  This semantics means all functions with
+the same mutex type(s) are part of a critical section for objects of that type
+and only one runs at a time.
 \subsection{Threads}
+While coroutines allow new things to be done with a single execution path
+threads actually introduce new paths of execution that continue independently.
+Now for threads to work together their must be some communication between them
+and that means the timing of certain operations does have to be known. There
+or various means of syncronization and mutual exclution provided by \CFA but
+for exceptions only the basic two -- fork and join -- are needed.
+Threads are created like coroutines except the keyword is changed:
+Functions, generators, and coroutines are sequential so there is only a single
+(but potentially sophisticated) execution path in a program. Threads introduce
+multiple execution paths that continue independently.
+For threads to work safely with objects requires mutual exclusion using
+monitors and mutex parameters. For threads to work safely with other threads,
+also requires mutual exclusion in the form of a communication rendezvous, which
+also supports internal synchronization as for mutex objects. For exceptions
+only the basic two basic operations are important: thread fork and join.
+Threads are created like coroutines with an associated @main@ function:
 \begin{cfa}
 thread StringWorker {
     const char * input;
     int result;
+        const char * input;
+        int result;
 };
 void main(StringWorker & this) {
+    const char * localCopy = this.input;
+    // ... do some work, perhaps hashing the string ...
+    this.result = result;
+}
+\end{cfa}
+The main function will start executing after the fork operation and continue
+executing until it is finished. If another thread joins with this one it will
+wait until main has completed execution. In other words everything the thread
+does is between fork and join.
+From the outside this is the creation and destruction of the thread object.
+Fork happens after the constructor is run and join happens before the
+destructor runs. Join also happens during the @join@ function which
+can be used to join a thread earlier. If it is used the destructor does not
+join as that has already been completed.
+        const char * localCopy = this.input;
+        // ... do some work, perhaps hashing the string ...
+        this.result = result;
+}
+{
+        StringWorker stringworker; // fork thread running in "main"
+} // implicitly join with thread $\(\Rightarrow\)$ wait for completion
+\end{cfa}
+The thread main is where a new thread starts execution after a fork operation
+and then the thread continues executing until it is finished. If another thread
+joins with an executing thread, it waits until the executing main completes
+execution. In other words, everything a thread does is between a fork and join.
+From the outside, this behaviour is accomplished through creation and
+destruction of a thread object.  Implicitly, fork happens after a thread
+object's constructor is run and join happens before the destructor runs. Join
+can also be specified explicitly using the @join@ function to wait for a
+thread's completion independently from its deallocation (\ie destructor
+call). If @join@ is called explicitly, the destructor does not implicitly join.

doc/theses/andrew_beach_MMath/features.tex

-                      rcd70477
+                      rf99f5ba
+\chapter{Features}
+This chapter covers the design and user interface of the \CFA exception
+handling mechanism.
+\section{Virtual Casts}
+Virtual casts and virtual types are not truly part of the exception system but
+they did not exist in \CFA and are useful in exceptions. So a minimal version
+of they virtual system was designed and implemented.
+Virtual types are organized in simple hierarchies. Each virtual type may have
+a parent and can have any number of children. A type's descendants are its
+children and its children's descendants. A type may not be its own descendant.
+Each virtual type has an associated virtual table type. A virtual table is a
+structure that has fields for all the virtual members of a type. A virtual
+type has all the virtual members of its parent and can add more. It may also
+update the values of the virtual members and should in many cases.
+Except for virtual casts, this is only used internally in the exception
+system. There is no general purpose interface for the other features. A
+a virtual cast has the following syntax:
+\begin{lstlisting}
+\chapter{Exception Features}
+This chapter covers the design and user interface of the \CFA
+exception-handling mechanism.
+\section{Virtuals}
+Virtual types and casts are not required for a basic exception-system but are
+useful for advanced exception features. However, \CFA is not object-oriented so
+there is no obvious concept of virtuals.  Hence, to create advanced exception
+features for this work, I needed to designed and implemented a virtual-like
+system for \CFA.
+Object-oriented languages often organized exceptions into a simple hierarchy,
+\eg Java.
+\begin{center}
+\setlength{\unitlength}{4000sp}%
+\begin{picture}(1605,612)(2011,-1951)
+\put(2100,-1411){\vector(1, 0){225}}
+\put(3450,-1411){\vector(1, 0){225}}
+\put(3550,-1411){\line(0,-1){225}}
+\put(3550,-1636){\vector(1, 0){150}}
+\put(3550,-1636){\line(0,-1){225}}
+\put(3550,-1861){\vector(1, 0){150}}
+\put(2025,-1490){\makebox(0,0)[rb]{\LstBasicStyle{exception}}}
+\put(2400,-1460){\makebox(0,0)[lb]{\LstBasicStyle{arithmetic}}}
+\put(3750,-1460){\makebox(0,0)[lb]{\LstBasicStyle{underflow}}}
+\put(3750,-1690){\makebox(0,0)[lb]{\LstBasicStyle{overflow}}}
+\put(3750,-1920){\makebox(0,0)[lb]{\LstBasicStyle{zerodivide}}}
+\end{picture}%
+\end{center}
+The hierarchy provides the ability to handle an exception at different degrees
+of specificity (left to right).  Hence, it is possible to catch a more general
+exception-type in higher-level code where the implementation details are
+unknown, which reduces tight coupling to the lower-level implementation.
+Otherwise, low-level code changes require higher-level code changes, \eg,
+changing from raising @underflow@ to @overflow@ at the low level means changing
+the matching catch at the high level versus catching the general @arithmetic@
+exception. In detail, each virtual type may have a parent and can have any
+number of children. A type's descendants are its children and its children's
+descendants. A type may not be its own descendant.
+The exception hierarchy allows a handler (@catch@ clause) to match multiple
+exceptions, \eg a base-type handler catches both base and derived
+exception-types.
+\begin{cfa}
+try {
+        ...
+} catch(arithmetic &) {
+        ... // handle arithmetic, underflow, overflow, zerodivide
+}
+\end{cfa}
+Most exception mechanisms perform a linear search of the handlers and select
+the first matching handler, so the order of handers is now important because
+matching is many to one.
+Each virtual type needs an associated virtual table. A virtual table is a
+structure with fields for all the virtual members of a type. A virtual type has
+all the virtual members of its parent and can add more. It may also update the
+values of the virtual members and often does.
+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 \CC \lstinline[language=C++]|dynamic_cast|.
+\label{p:VirtualCast}
+\begin{cfa}
 (virtual TYPE)EXPRESSION
+\end{lstlisting}
+This has the same precedence as a traditional C-cast and can be used in the
+same places. This will convert the result of EXPRESSION to the type TYPE. Both
+the type of EXPRESSION and TYPE must be pointers to virtual types.
+The cast is checked and will either return the original value or null, based
+on the result of the check. The check is does the object pointed at have a
+type that is a descendant of the target type. If it is the result is the
+pointer, otherwise the result is null.
+\section{Exceptions}
+\end{cfa}
+Note, the syntax and semantics matches a C-cast, rather than the unusual \CC
+syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be a
+pointer to a virtual type. The cast dynamically checks if the @EXPRESSION@ type
+is the same or a subtype of @TYPE@, and if true, returns a pointer to the
+@EXPRESSION@ object, otherwise it returns @0p@ (null pointer).
+\section{Exception}
 % Leaving until later, hopefully it can talk about actual syntax instead
 % of my many strange macros. Syntax aside I will also have to talk about the
 % features all exceptions support.
+\subsection{Exception Traits}
+Exceptions are defined by the trait system; there are a series of traits and
+if a type satisfies them then they can be used as exceptions.
+\begin{lstlisting}
+trait is_exception(dtype exceptT, dtype virtualT) {
+    virtualT const & get_exception_vtable(exceptT *);
+Exceptions are defined by the trait system; there are a series of traits, and
+if a type satisfies them, then it can be used as an exception.  The following
+is the base trait all exceptions need to match.
+\begin{cfa}
+trait is_exception(exceptT &, virtualT &) {
+        virtualT const & @get_exception_vtable@(exceptT *);
 };
+\end{lstlisting}
+This is the base trait that all exceptions need to match.
+The single function takes any pointer (including the null pointer) and
+returns a reference to the virtual table instance. Defining this function
+also establishes the virtual type and virtual table pair to the resolver
+and promises that @exceptT@ is a virtual type and a child of the
+base exception type.
+One odd thing about @get_exception_vtable@ is that it should always
+be a constant function, returning the same value regardless of its argument.
+A pointer or reference to the virtual table instance could be used instead,
+however using a function has some ease of implementation advantages and
+allows for easier disambiguation because the virtual type name (or the
+address of an instance that is in scope) can be used instead of the mangled
+virtual table name.
+Also note the use of the word ``promise" in the trait description. \CFA
+cannot currently check to see if either @exceptT@ or
+@virtualT@ match the layout requirements. Currently this is
+considered part of @get_exception_vtable@'s correct implementation.
+\begin{lstlisting}
+\end{cfa}
+The function takes any pointer, including the null pointer, and returns a
+reference to the virtual-table object. Defining this function also establishes
+the virtual type and a virtual-table pair to the \CFA type-resolver and
+promises @exceptT@ is a virtual type and a child of the base exception-type.
+\PAB{I do not understand this paragraph.}
+One odd thing about @get_exception_vtable@ is that it should always be a
+constant function, returning the same value regardless of its argument.  A
+pointer or reference to the virtual table instance could be used instead,
+however using a function has some ease of implementation advantages and allows
+for easier disambiguation because the virtual type name (or the address of an
+instance that is in scope) can be used instead of the mangled virtual table
+name.  Also note the use of the word ``promise'' in the trait
+description. Currently, \CFA cannot check to see if either @exceptT@ or
+@virtualT@ match the layout requirements. This is considered part of
+@get_exception_vtable@'s correct implementation.
+\section{Raise}
+\CFA provides two kinds of exception raise: termination
+\see{\VRef{s:Termination}} and resumption \see{\VRef{s:Resumption}}, which are
+specified with the following traits.
+\begin{cfa}
 trait is_termination_exception(
         dtype exceptT, dtype virtualT | is_exception(exceptT, virtualT)) {
     void defaultTerminationHandler(exceptT &);
+                exceptT &, virtualT & | is_exception(exceptT, virtualT)) {
+        void @defaultTerminationHandler@(exceptT &);
 };
+\end{lstlisting}
+The only additional function required to make the exception usable with
+termination is a default handler. This function is called whenever a
+termination throw on an exception of this type is preformed and no handler
+is found.
+\begin{lstlisting}
+\end{cfa}
+The function is required to allow a termination raise, but is only called if a
+termination raise does not find an appropriate handler.
+Allowing a resumption raise is similar.
+\begin{cfa}
 trait is_resumption_exception(
         dtype exceptT, dtype virtualT | is_exception(exceptT, virtualT)) {
     void defaultResumptionHandler(exceptT &);
+                exceptT &, virtualT & | is_exception(exceptT, virtualT)) {
+        void @defaultResumptionHandler@(exceptT &);
 };
+\end{lstlisting}
+Creating a resumption exception is exactly the same except for resumption.
+The name change reflects that and the function is called when a resumption
+throw on an exception of this type is preformed and no handler is found.
+Finally there are three additional macros that can be used to refer to the
+these traits. They are @IS_EXCEPTION@,
+@IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@.
+Each takes the virtual type's name and, for polymorphic types only, the
+parenthesized list of polymorphic arguments. These do the name mangling to
+get the virtual table name and provide the arguments to both sides.
+\section{Termination}
+Termination exception throws are likely the most familiar kind, as they are
+used in several popular programming languages. A termination will throw an
+exception, search the stack for a handler, unwind the stack to where the
+handler is defined, execute the handler and then continue execution after
+the handler. They are used when execution cannot continue here.
+Termination has two pieces of syntax it uses. The first is the throw:
+\begin{lstlisting}
+\end{cfa}
+The function is required to allow a resumption raise, but is only called if a
+resumption raise does not find an appropriate handler.
+Finally there are three convenience macros for referring to the these traits:
+@IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@.  Each
+takes the virtual type's name, and for polymorphic types only, the
+parenthesized list of polymorphic arguments. These macros do the name mangling
+to get the virtual-table name and provide the arguments to both sides
+\PAB{What's a ``side''?}
+\subsection{Termination}
+\label{s:Termination}
+Termination raise, called ``throw'', is familiar and used in most programming
+languages with exception handling. The semantics of termination is: search the
+stack for a matching handler, unwind the stack frames to the matching handler,
+execute the handler, and continue execution after the handler. Termination is
+used when execution \emph{cannot} return to the throw. To continue execution,
+the program must \emph{recover} in the handler from the failed (unwound)
+execution at the raise to safely proceed after the handler.
+A termination raise is started with the @throw@ statement:
+\begin{cfa}
 throw EXPRESSION;
+\end{lstlisting}
+The expression must evaluate to a reference to a termination exception. A
+termination exception is any exception with a
+@void defaultTerminationHandler(T &);@ (the default handler) defined
+on it. The handler is taken from the call sight with \CFA's trait system and
+passed into the exception system along with the exception itself.
+The exception passed into the system is then copied into managed memory.
+This is to ensure it remains in scope during unwinding. It is the user's
+responsibility to make sure the original exception is freed when it goes out
+of scope. Being allocated on the stack is sufficient for this.
+Then the exception system will search the stack starting from the throw and
+proceeding towards the base of the stack, from callee to caller. As it goes
+it will check any termination handlers it finds:
+\begin{lstlisting}
+try {
+    TRY_BLOCK
+} catch (EXCEPTION_TYPE * NAME) {
+    HANDLER
+}
+\end{lstlisting}
+This shows a try statement with a single termination handler. The statements
+in TRY\_BLOCK will be executed when control reaches this statement. While
+those statements are being executed if a termination exception is thrown and
+it is not handled by a try statement further up the stack the EHM will check
+all of the terminations handlers attached to the try block, top to bottom.
+At each handler the EHM will check to see if the thrown exception is a
+descendant of EXCEPTION\_TYPE. If it is the pointer to the exception is
+bound to NAME and the statements in HANDLER are executed. If control reaches
+the end of the handler then it exits the block, the exception is freed and
+control continues after the try statement.
+The default handler is only used if no handler for the exception is found
+after the entire stack is searched. When that happens the default handler
+is called with a reference to the exception as its only argument. If the
+handler returns control continues from after the throw statement.
+\paragraph{Conditional Catches}
+Catch clauses may also be written as:
+\begin{lstlisting}
+catch (EXCEPTION_TYPE * NAME ; CONDITION)
+\end{lstlisting}
+This has the same behaviour as a regular catch clause except that if the
+exception matches the given type the condition is also run. If the result is
+true only then is this considered a matching handler. If the result is false
+then the handler does not match and the search continues with the next clause
+in the try block.
+The condition considers all names in scope at the beginning of the try block
+to be in scope along with the name introduce in the catch clause itself.
+\paragraph{Re-Throwing}
+You can also re-throw the most recent termination exception with
+@throw;@. % This is terrible and you should never do it.
+This can be done in a handler or any function that could be called from a
+handler.
+This will start another termination throw reusing the exception, meaning it
+does not copy the exception or allocated any more memory for it. However the
+default handler is still at the original through and could refer to data that
+was on the unwound section of the stack. So instead a new default handler that
+does a program level abort is used.
+\section{Resumption}
+Resumption exceptions are less popular then termination but in many
+regards are simpler and easier to understand. A resumption throws an exception,
+searches for a handler on the stack, executes that handler on top of the stack
+and then continues execution from the throw. These are used when a problem
+needs to be fixed before execution continues.
+A resumption is thrown with a throw resume statement:
+\begin{lstlisting}
+\end{cfa}
+The expression must return a termination-exception reference, where the
+termination exception has a type with a @void defaultTerminationHandler(T &)@
+(default handler) defined. The handler is found at the call site using \CFA's
+trait system and passed into the exception system along with the exception
+itself.
+At runtime, a representation of the exception type and an instance of the
+exception type is copied into managed memory (heap) to ensure it remains in
+scope during unwinding. It is the user's responsibility to ensure the original
+exception object at the throw is freed when it goes out of scope. Being
+allocated on the stack is sufficient for this.
+Then the exception system searches the stack starting from the throw and
+proceeding towards the base of the stack, from callee to caller. At each stack
+frame, a check is made for termination handlers defined by the @catch@ clauses
+of a @try@ statement.
+\begin{cfa}
+try {
+        GUARDED_BLOCK
+} @catch (EXCEPTION_TYPE$\(_1\)$ * NAME)@ { // termination handler 1
+        HANDLER_BLOCK$\(_1\)$
+} @catch (EXCEPTION_TYPE$\(_2\)$ * NAME)@ { // termination handler 2
+        HANDLER_BLOCK$\(_2\)$
+}
+\end{cfa}
+The statements in the @GUARDED_BLOCK@ are executed. If those statements, or any
+functions invoked from those statements, throws an exception, and the exception
+is not handled by a try statement further up the stack, the termination
+handlers are searched for a matching exception type from top to bottom.
+Exception matching checks the representation of the thrown exception-type is
+the same or a descendant type of the exception types in the handler clauses. If
+there is a match, a pointer to the exception object created at the throw is
+bound to @NAME@ and the statements in the associated @HANDLER_BLOCK@ are
+executed. If control reaches the end of the handler, the exception is freed,
+and control continues after the try statement.
+The default handler visible at the throw statement is used if no matching
+termination handler is found after the entire stack is searched. At that point,
+the default handler is called with a reference to the exception object
+generated at the throw. If the default handler returns, the system default
+action is executed, which often terminates the program. This feature allows
+each exception type to define its own action, such as printing an informative
+error message, when an exception is not handled in the program.
+\subsection{Resumption}
+\label{s:Resumption}
+Resumption raise, called ``resume'', is as old as termination
+raise~\cite{Goodenough75} but is less popular. In many ways, resumption is
+simpler and easier to understand, as it is simply a dynamic call (as in
+Lisp). The semantics of resumption is: search the stack for a matching handler,
+execute the handler, and continue execution after the resume. Notice, the stack
+cannot be unwound because execution returns to the raise point. Resumption is
+used used when execution \emph{can} return to the resume. To continue
+execution, the program must \emph{correct} in the handler for the failed
+execution at the raise so execution can safely continue after the resume.
+A resumption raise is started with the @throwResume@ statement:
+\begin{cfa}
 throwResume EXPRESSION;
+\end{lstlisting}
+The result of EXPRESSION must be a resumption exception type. A resumption
+exception type is any type that satisfies the assertion
+@void defaultResumptionHandler(T &);@ (the default handler). When the
+statement is executed the expression is evaluated and the result is thrown.
+Handlers are declared using clauses in try statements:
+\begin{lstlisting}
+try {
+    TRY_BLOCK
+} catchResume (EXCEPTION_TYPE * NAME) {
+    HANDLER
+}
+\end{lstlisting}
+This is a simple example with the try block and a single resumption handler.
+Multiple resumption handlers can be put in a try statement and they can be
+mixed with termination handlers.
+When a resumption begins it will start searching the stack starting from
+the throw statement and working its way to the callers. In each try statement
+handlers will be tried top to bottom. Each handler is checked by seeing if
+the thrown exception is a descendant of EXCEPTION\_TYPE. If not the search
+continues. Otherwise NAME is bound to a pointer to the exception and the
+HANDLER statements are executed. After they are finished executing control
+continues from the throw statement.
+If no appropriate handler is found then the default handler is called. The
+throw statement acts as a regular function call passing the exception to
+the default handler and after the handler finishes executing control continues
+from the throw statement.
+The exception system also tracks the position of a search on the stack. If
+another resumption exception is thrown while a resumption handler is running
+it will first check handlers pushed to the stack by the handler and any
+functions it called, then it will continue from the try statement that the
+handler is a part of; except for the default handler where it continues from
+the throw the default handler was passed to.
+This makes the search pattern for resumption reflect the one for termination,
+which is what most users expect.
+\end{cfa}
+The semantics of the @throwResume@ statement are like the @throw@, but the
+expression has a type with a @void defaultResumptionHandler(T &)@ (default
+handler) defined, where the handler is found at the call site by the type
+system.  At runtime, a representation of the exception type and an instance of
+the exception type is \emph{not} copied because the stack is maintained during
+the handler search.
+Then the exception system searches the stack starting from the resume and
+proceeding towards the base of the stack, from callee to caller. At each stack
+frame, a check is made for resumption handlers defined by the @catchResume@
+clauses of a @try@ statement.
+\begin{cfa}
+try {
+        GUARDED_BLOCK
+} @catchResume (EXCEPTION_TYPE$\(_1\)$ * NAME)@ { // resumption handler 1
+        HANDLER_BLOCK$\(_1\)$
+} @catchResume (EXCEPTION_TYPE$\(_2\)$ * NAME)@ { // resumption handler 2
+        HANDLER_BLOCK$\(_2\)$
+}
+\end{cfa}
+The statements in the @GUARDED_BLOCK@ are executed. If those statements, or any
+functions invoked from those statements, resumes an exception, and the
+exception is not handled by a try statement further up the stack, the
+resumption handlers are searched for a matching exception type from top to
+bottom. (Note, termination and resumption handlers may be intermixed in a @try@
+statement but the kind of raise (throw/resume) only matches with the
+corresponding kind of handler clause.)
+The exception search and matching for resumption is the same as for
+termination, including exception inheritance. The difference is when control
+reaches the end of the handler: the resumption handler returns after the resume
+rather than after the try statement. The resume point assumes the handler has
+corrected the problem so execution can safely continue.
+Like termination, if no resumption handler is found, the default handler
+visible at the resume statement is called, and the system default action is
+executed.
+For resumption, the exception system uses stack marking to partition the
+resumption search. If another resumption exception is raised in a resumption
+handler, the second exception search does not start at the point of the
+original raise. (Remember the stack is not unwound and the current handler is
+at the top of the stack.) The search for the second resumption starts at the
+current point on the stack because new try statements may have been pushed by
+the handler or functions called from the handler. If there is no match back to
+the point of the current handler, the search skips\label{p:searchskip} the stack frames already
+searched by the first resume and continues after the try statement. The default
+handler always continues from default handler associated with the point where
+the exception is created.
 % This might need a diagram. But it is an important part of the justification
 % of the design of the traversal order.
+It also avoids the recursive resumption problem. If the entire stack is
+searched loops of resumption can form. Consider a handler that handles an
+exception of type A by resuming an exception of type B and on the same stack,
+later in the search path, is a second handler that handles B by resuming A.
+Assuming no other handlers on the stack handle A or B then in either traversal
+system an A resumed from the top of the stack will be handled by the first
+handler. A B resumed from the top or from the first handler it will be handled
+by the second handler. The only difference is when A is thrown from the second
+handler. The entire stack search will call the first handler again, creating a
+loop. Starting from the position in the stack though will break this loop.
+\paragraph{Conditional Catches}
+Resumption supports conditional catch clauses like termination does. They
+use the same syntax except the keyword is changed:
+\begin{lstlisting}
+catchResume (EXCEPTION_TYPE * NAME ; CONDITION)
+\end{lstlisting}
+It also has the same behaviour, after the exception type has been matched
+with the EXCEPTION\_TYPE the CONDITION is evaluated with NAME in scope. If
+the result is true then the handler is run, otherwise the search continues
+just as if there had been a type mismatch.
+\paragraph{Re-Throwing}
+You may also re-throw resumptions with a @throwResume;@ statement.
+This can only be done from inside of a @catchResume@ block.
+Outside of any side effects of any code already run in the handler this will
+have the same effect as if the exception had not been caught in the first
+place.
+\begin{verbatim}
+       throwResume2 ----------.
+            |                 |
+ generated from handler       |
+            |                 |
+         handler              |
+            |                 |
+        throwResume1 -----.   :
+            |             |   :
+           try            |   : search skip
+            |             |   :
+        catchResume  <----'   :
+            |                 |
+\end{verbatim}
+This resumption search-pattern reflect the one for termination, which matches
+with programmer expectations. However, it avoids the \emph{recursive
+resumption} problem. If parts of the stack are searched multiple times, loops
+can easily form resulting in infinite recursion.
+Consider the trivial case:
+\begin{cfa}
+try {
+        throwResume$\(_1\)$ (E &){};
+} catch( E * ) {
+        throwResume;
+}
+\end{cfa}
+Based on termination semantics, programmer expectation is for the re-resume to
+continue searching the stack frames after the try statement. However, the
+current try statement is still on the stack below the handler issuing the
+reresume \see{\VRef{s:Reraise}}. Hence, the try statement catches the re-raise
+again and does another re-raise \emph{ad infinitum}, which is confusing and
+difficult to debug. The \CFA resumption search-pattern skips the try statement
+so the reresume search continues after the try, mathcing programmer
+expectation.
+\section{Conditional Catch}
+Both termination and resumption handler-clauses may perform conditional matching:
+\begin{cfa}
+catch (EXCEPTION_TYPE * NAME ; @CONDITION@)
+\end{cfa}
+First, the same semantics is used to match the exception type. Second, if the
+exception matches, @CONDITION@ is executed. The condition expression may
+reference all names in scope at the beginning of the try block and @NAME@
+introduced in the handler clause.  If the condition is true, then the handler
+matches. Otherwise, the exception search continues at the next appropriate kind
+of handler clause in the try block.
+\begin{cfa}
+try {
+        f1 = open( ... );
+        f2 = open( ... );
+        ...
+} catch( IOFailure * f ; fd( f ) == f1 ) {
+        // only handle IO failure for f1
+}
+\end{cfa}
+Note, catching @IOFailure@, checking for @f1@ in the handler, and reraising the
+exception if not @f1@ is different because the reraise does not examine any of
+remaining handlers in the current try statement.
+\section{Reraise}
+\label{s:Reraise}
+Within the handler block or functions called from the handler block, it is
+possible to reraise the most recently caught exception with @throw@ or
+@throwResume@, respective.
+\begin{cfa}
+catch( ... ) {
+        ... throw; // rethrow
+} catchResume( ... ) {
+        ... throwResume; // reresume
+}
+\end{cfa}
+The only difference between a raise and a reraise is that reraise does not
+create a new exception; instead it continues using the current exception, \ie
+no allocation and copy. However the default handler is still set to the one
+visible at the raise point, and hence, for termination could refer to data that
+is part of an unwound stack frame. To prevent this problem, a new default
+handler is generated that does a program-level abort.
 \section{Finally Clauses}
+A @finally@ clause may be placed at the end of a try statement after
+all the handler clauses. In the simply case, with no handlers, it looks like
+this:
+\begin{lstlisting}
+try {
+    TRY_BLOCK
+A @finally@ clause may be placed at the end of a @try@ statement.
+\begin{cfa}
+try {
+        GUARDED_BLOCK
+} ...   // any number or kind of handler clauses
 } finally {
+    FINAL_STATEMENTS
+}
+\end{lstlisting}
+Any number of termination handlers and resumption handlers may proceed the
+finally clause.
+The FINAL\_STATEMENTS, the finally block, are executed whenever the try
+statement is removed from the stack. This includes: the TRY\_BLOCK finishes
+executing, a termination exception finishes executing and the stack unwinds.
+Execution of the finally block should finish by letting control run off
+the end of the block. This is because after the finally block is complete
+control will continue to where ever it would if the finally clause was not
+present.
+Because of this local control flow out of the finally block is forbidden.
+The compiler rejects uses of @break@, @continue@,
+@fallthru@ and @return@ that would cause control to leave
+the finally block. Other ways to leave the finally block - such as a long
+jump or termination - are much harder to check, at best requiring additional
+run-time overhead, and so are merely discouraged.
+        FINALLY_BLOCK
+}
+\end{cfa}
+The @FINALLY_BLOCK@ is executed when the try statement is unwound from the
+stack, \ie when the @GUARDED_BLOCK@ or any handler clause finishes. Hence, the
+finally block is always executed.
+Execution of the finally block should always finish, meaning control runs off
+the end of the block. This requirement ensures always continues as if the
+finally clause is not present, \ie finally is for cleanup not changing control
+flow.  Because of this requirement, local control flow out of the finally block
+is forbidden.  The compiler precludes any @break@, @continue@, @fallthru@ or
+@return@ that causes control to leave the finally block. Other ways to leave
+the finally block, such as a long jump or termination are much harder to check,
+and at best requiring additional run-time overhead, and so are discouraged.
 \section{Cancellation}
+Cancellation can be thought of as a stack-level abort or as an uncatchable
+termination. It unwinds the entirety of the current exception and if possible
+passes an exception to a different stack as a message.
+There is no special statement for starting a cancellation, instead you call
+the standard library function @cancel\_stack@ which takes an exception.
+Unlike in a throw this exception is not used in control flow but is just there
+to pass information about why the cancellation happened.
+The handler is decided entirely by which stack is being canceled. There are
+three handlers that apply to three different groups of stacks:
+\begin{itemize}
+\item Main Stack:
+The main stack is the one on which the program main is called at the beginning
+of your program. It is also the only stack you have without the libcfathreads.
+Because of this there is no other stack ``above" (or possibly at all) for main
+to notify when a cancellation occurs. So after the stack is unwound we do a
+program level abort.
+\item Thread Stack:
+Thread stacks are those created @thread@ or otherwise satisfy the
+@is\_thread@ trait.
+Threads only have two structural points of communication that must happen,
+start and join. As the thread must be running to preform a cancellation it
+will be after start and before join, so join is one cancellation uses.
+After the stack is unwound the thread will halt as if had completed normally
+and wait for another thread to join with it. The other thread, when it joins,
+checks for a cancellation. If so it will throw the resumption exception
+@ThreadCancelled@.
+There is a difference here in how explicate joins (with the @join@
+function) and implicate joins (from a destructor call). Explicate joins will
+take the default handler (@defaultResumptionHandler@) from the context
+and use like a regular through does if the exception is not caught. The
+implicate join does a program abort instead.
+This is for safety. One of the big problems in exceptions is you cannot handle
+two terminations or cancellations on the same stack as either can destroy the
+context required for the other. This can happen with join but as the
+destructors will always be run when the stack is being unwound and one
+Cancellation is a stack-level abort, which can be thought of as as an
+uncatchable termination. It unwinds the entirety of the current stack, and if
+possible forwards the cancellation exception to a different stack.
+There is no special statement for starting a cancellation; instead the standard
+library function @cancel_stack@ is called passing an exception.  Unlike a
+raise, this exception is not used in matching only to pass information about
+the cause of the cancellation.
+Handling of a cancellation depends on which stack is being cancelled.
+\begin{description}
+\item[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.  Hence, when cancellation is
+forwarded to the main stack, there is no other forwarding stack, so after the
+stack is unwound, there is a program-level abort.
+\item[Thread Stack:]
+A thread stack is created for a @thread@ object or object that satisfies the
+@is_thread@ trait.  A thread only has two points of communication that must
+happen: start and join. As the thread must be running to perform a
+cancellation, it must occur after start and before join, so join is a
+cancellation point.  After the stack is unwound, the thread halts and waits for
+another thread to join with it. The joining thread, checks for a cancellation,
+and if present, resumes exception @ThreadCancelled@.
+There is a subtle difference between the explicit join (@join@ function) and
+implicit join (from a destructor call). The explicit join takes the default
+handler (@defaultResumptionHandler@) from its calling context, which is used if
+the exception is not caught. The implicit join does a program abort instead.
+This semantics is for safety. One difficult problem for any exception system is
+defining semantics when an exception is raised during an exception search:
+which exception has priority, the original or new exception? No matter which
+exception is selected, it is possible for the selected one to disrupt or
+destroy the context required for the other. \PAB{I do not understand the
+following sentences.} This loss of information can happen with join but as the
+thread destructor is always run when the stack is being unwound and one
 termination/cancellation is already active. Also since they are implicit they
 are easier to forget about.
+\item Coroutine Stack:
+Coroutine stacks are those created with @coroutine@ or otherwise
+satisfy the @is\_coroutine@ trait.
+A coroutine knows of two other coroutines, its starter and its last resumer.
+The last resumer is ``closer" so that is the one notified.
+After the stack is unwound control goes to the last resumer.
+Resume will resume throw a @CoroutineCancelled@ exception, which is
+polymorphic over the coroutine type and has a pointer to the coroutine being
+canceled and the canceling exception. The resume function also has an
+assertion that the @defaultResumptionHandler@ for the exception. So it
+will use the default handler like a regular throw.
+\end{itemize}
+\item[Coroutine Stack:] A coroutine stack is created for a @coroutine@ object
+or object that satisfies the @is_coroutine@ trait.  A coroutine only knows of
+two other coroutines, its starter and its last resumer.  The last resumer has
+the tightest coupling to the coroutine it activated.  Hence, cancellation of
+the active coroutine is forwarded to the last resumer after the stack is
+unwound, as the last resumer has the most precise knowledge about the current
+execution. When the resumer restarts, it resumes exception
+@CoroutineCancelled@, which is polymorphic over the coroutine type and has a
+pointer to the cancelled coroutine.
+The resume function also has an assertion that the @defaultResumptionHandler@
+for the exception. So it will use the default handler like a regular throw.
+\end{description}

doc/theses/andrew_beach_MMath/future.tex

-                      rcd70477
+                      rf99f5ba
 \chapter{Future Work}
+\section{Language Improvements}
+\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.
+\begin{itemize}
+\item
+The implementation of termination is not portable because it includes
+hand-crafted assembly statements. These sections must be generalized to support
+more hardware architectures, \eg ARM processor.
+\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.
+\item
+Termination handlers cannot use local control-flow transfers, \eg by @break@,
+@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.
+\end{itemize}
 \section{Complete Virtual System}
 The virtual system should be completed. It was never supposed to be part of
+this project and so minimal work was done on it. A draft of what the complete
+system might look like was created but it was never finalized or implemented.
+A future project in \CFA would be to complete that work and to update the
 parts of the exception system that use the current version.
+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
+it is not finalized.  A future \CFA project is to complete that work and then
+update the exception system that uses the current version.
 There are several improvements to the virtual system that would improve
+the exception traits. The biggest one is an assertion that checks that one
+virtual type is a child of another virtual type. This would capture many of
 the requirements much more precisely.
+There are several improvements to the virtual system that would improve the
+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.
 The full virtual system might also include other improvement like associated
+types. This is a proposed feature that would allow traits to refer to types
+not listed in their header. This would allow the exception traits to not
+refer to the virtual table type explicatly which would remove the need for
+the interface macros.
+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.
+\section{Additional Throws}
+Several other kinds of throws, beyond the termination throw (@throw@),
+the resumption throw (@throwResume@) and the re-throws, were considered.
+None were as useful as the core throws but they would likely be worth
+revising.
+\section{Additional Raises}
+Several other kinds of exception raises were considered beyond termination
+(@throw@), resumption (@throwResume@), and reraise.
+The first ones are throws for asynchronous exceptions, throwing exceptions
+from one stack to another. These act like signals allowing for communication
+between the stacks. This is usually used with resumption as it allows the
+target stack to continue execution normally after the exception has been
+handled.
+The first is a non-local/concurrent raise providing asynchronous exceptions,
+\ie raising an exception on another stack. This semantics acts like signals
+allowing for out-of-band communication among coroutines and threads. This kind
+of raise is often restricted to resumption to allow the target stack to
+continue execution normally after the exception has been handled. That is,
+allowing one coroutine/thread to unwind the stack of another via termination is
+bad software engineering.
+This would much more coordination between the concurrency system and the
+exception system to handle. Most of the interesting design decisions around
 applying asynchronous exceptions appear to be around masking (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.
+Non-local/concurrent 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
+would likely require more of the virtual system and would also effect how
+default handlers are set.
 The other throws were designed to mimic bidirectional algebraic effects.
 Algebraic effects are used in some functional languages and allow a function
+Other raises were considered to mimic bidirectional algebraic effects.
+Algebraic effects are used in some functional languages allowing one function
 to have another function on the stack resolve an effect (which is defined with
+a function-like interface).
+These can be mimiced with resumptions and the the new throws were designed
+to try and mimic bidirectional algebraic effects, where control can go back
+and forth between the function effect caller and handler while the effect
+is underway.
+a functional-like interface).  This semantics can be mimicked with resumptions
+and new raises were discussed to mimic bidirectional algebraic-effects, where
+control can go back and forth between the function-effect caller and handler
+while the effect is underway.
 % resume-top & resume-reply
+These raises would be like the resumption raise except using different search
+patterns to find the handler.
+These throws would likely be just like the resumption throw except they would
+use different search patterns to find the handler to reply to.
+\section{Zero-Cost Try}
+\CFA does not have zero-cost try-statements because the compiler generates C
+code rather than assembler code \see{\VPageref{p:zero-cost}}. When the compiler
+does create its own assembly (or LLVM byte-code), then zero-cost try-statements
+are possible. The downside of zero-cost try-statements is the LSDA complexity,
+its size (program bloat), and the high cost of raising an exception.
+\section{Zero-Cost Exceptions}
+\CFA does not have zero-cost exceptions because it does not generate assembly
+but instead generates C code. See the implementation section. When the
+compiler does start to create its own assembly (or LLVM byte code) then
+zero-cost exceptions could be implemented.
+Alternatively, some research could be done into the simpler alternative method
+with a non-zero-cost try-statement but much lower cost exception raise. For
+example, programs are starting to use exception in the normal control path, so
+more exceptions are thrown. In these cases, the cost balance switches towards
+low-cost raise. Unfortunately, while exceptions remain exceptional, the
+libunwind model will probably remain the most effective option.
+Now in zero-cost exceptions the only part that is zero-cost are the try
+blocks. Some research could be done into the alternative methods for systems
+that expect a lot more exceptions to be thrown, allowing some overhead in
+entering and leaving try blocks to make throws faster. But while exceptions
+remain exceptional the libunwind model will probably remain the most effective
+option.
+Zero-cost resumptions is still an open problem. First, because libunwind does
+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.
+Zero-cost resumptions have more problems to solve. First because libunwind
+does not support a successful exiting stack search without doing an unwind.
+There are several ways to hack that functionality in. Ideally an extension to
+libunwind could be made, but that would either require seperate maintenance
+or gain enough support to have it folded into the standard.
+Also new techniques to skip previously searched parts of the stack will have
+to be developed. The recursive resume problem still remains and ideally the
+same pattern of ignoring sections of the stack.
+Also new techniques to skip previously searched parts of the stack need to be
+developed to handle the recursive resume problem and support advanced algebraic
+effects.
 \section{Signal Exceptions}
+Exception Handling: Issues and a Proposed Notation suggests there are three
+types of exceptions: escape, notify and signal.
+Escape exceptions are our termination exceptions, notify exceptions are
+resumption exceptions and that leaves signal exception unimplemented.
+Goodenough~\cite{Goodenough75} suggests three types of exceptions: escape,
+notify and signal.  Escape are termination exceptions, notify are resumption
+exceptions, leaving signal unimplemented.
+Signal exceptions allow either behaviour, that is after the exception is
+handled control can either return to the throw or from where the handler is
+defined.
+A signal exception allows either behaviour, \ie after an exception is handled,
+the handler has the option of returning to the raise or after the @try@
+statement. Currently, \CFA fixes the semantics of the handler return
+syntactically by the @catch@ or @catchResume@ clause.
+The design should be rexamined and be updated for \CFA. A very direct
 translation would perhaps have a new throw and catch pair and a statement
 (or statements) could be used to decide if the handler returns to the throw
 or continues where it is, but there are other options.
+Signal exception should be reexamined and possibly be supported in \CFA. A very
+direct translation is to have a new raise and catch pair, and a new statement
+(or statements) would indicate if the handler returns to the raise or continues
+where it is; but there may be other options.
 For instance resumption could be extended to cover this use by allowing
 local control flow out of it. This would require an unwind as part of the
 transition as there are stack frames that have to be removed.
+This would mean there is no notify like throw but because \CFA does not have
+exception signatures a termination can be thrown from any resumption handler
 already so there are already ways one could try to do this in existing \CFA.
+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.
 % Maybe talk about the escape; and escape CONTROL_STMT; statements or how
 % if we could choose if _Unwind_Resume proceeded to the clean-up stage this
 % would be much easier to implement.
-\section{Language Improvements}
-There is also a lot of work that are not follow ups to this work in terms of
-research, some have no interesting research to be done at all, but would
-improve \CFA as a programming language. The full list of these would
-naturally be quite extensive but here are a few examples that involve
-exceptions:
-\begin{itemize}
-\item The implementation of termination is not portable because it includes
-some assembly statements. These sections will have to be re-written to so
-\CFA has full support on more machines.
-\item Allowing exception handler to bind the exception to a reference instead
-of a pointer. This should actually result in no change in behaviour so there
-is no reason not to allow it. It is however a small improvement; giving a bit
-of flexibility to the user in what style they want to use.
-\item Enabling local control flow (by @break@, @return@ and
-similar statements) out of a termination handler. The current set-up makes
-this very difficult but the catch function that runs the handler after it has
-been matched could be inlined into the function's body, which would make this
-much easier. (To do the same for try blocks would probably wait for zero-cost
-exceptions, which would allow the try block to be inlined as well.)
-\end{itemize}

doc/theses/andrew_beach_MMath/implement.tex

-                      rcd70477
+                      rf99f5ba
 % Goes over how all the features are implemented.
+The implementation work for this thesis covers two components: the virtual
+system and exceptions. Each component is discussed in detail.
 \section{Virtual System}
+\label{s:VirtualSystem}
 % Virtual table rules. Virtual tables, the pointer to them and the cast.
+The \CFA virtual system only has one public facing feature: virtual casts.
+However there is a lot of structure to support that and provide some other
+features for the standard library.
+All of this is accessed through a field inserted at the beginning of every
+virtual type. Currently it is called @virtual_table@ but it is not
+ment to be accessed by the user. This field is a pointer to the type's
+virtual table instance. It is assigned once during the object's construction
+and left alone after that.
+\subsection{Virtual Table Construction}
+For each virtual type a virtual table is constructed. This is both a new type
+and an instance of that type. Other instances of the type could be created
+but the system doesn't use them. So this section will go over the creation of
+the type and the instance.
+Creating the single instance is actually very important. The address of the
+table acts as the unique identifier for the virtual type. Similarly the first
+field in every virtual table is the parent's id; a pointer to the parent
+virtual table instance.
+The remaining fields contain the type's virtual members. First come the ones
+present on the parent type, in the same order as they were the parent, and
+then any that this type introduces. The types of the ones inherited from the
+parent may have a slightly modified type, in that references to the
+dispatched type are replaced with the current virtual type. These are always
+taken by pointer or reference.
+The structure itself is created where the virtual type is created. The name
+of the type is created by mangling the name of the base type. The name of the
+instance is also generated by name mangling.
+The fields are initialized automatically.
+While the \CFA virtual system currently has only one public feature, virtual
+cast \see{\VPageref{p:VirtualCast}}, substantial structure is required to
+support it, and provide features for exception handling and the standard
+library.
+\subsection{Virtual Table}
+The virtual system is accessed through a private constant field inserted at the
+beginning of every virtual type, called the virtual-table pointer. This field
+points at a type's virtual table and is assigned during the object's
+construction.  The address of a virtual table acts as the unique identifier for
+the virtual type, and the first field of a virtual table is a pointer to the
+parent virtual-table or @0p@.  The remaining fields are duplicated from the
+parent tables in this type's inheritance chain, followed by any fields this type
+introduces. Parent fields are duplicated so they can be changed (\CC
+\lstinline[language=c++]|override|), so that references to the dispatched type
+are replaced with the current virtual type.
+\PAB{Can you create a simple diagram of the layout?}
+% These are always taken by pointer or reference.
+% For each virtual type, a virtual table is constructed. This is both a new type
+% and an instance of that type. Other instances of the type could be created
+% but the system doesn't use them. So this section will go over the creation of
+% the type and the instance.
+A virtual table is created when the virtual type is created. The name of the
+type is created by mangling the name of the base type. The name of the instance
+is also generated by name mangling.  The fields are initialized automatically.
 The parent field is initialized by getting the type of the parent field and
 using that to calculate the mangled name of the parent's virtual table type.
 There are two special fields that are included like normal fields but have
 special initialization rules: the @size@ field is the type's size and is
+initialized with a sizeof expression, the @align@ field is the type's
+alignment and uses an alignof expression. The remaining fields are resolved
+to a name matching the field's name and type using the normal visibility
+and overload resolution rules of the type system.
+These operations are split up into several groups depending on where they
+take place which can vary for monomorphic and polymorphic types. The first
+devision is between the declarations and the definitions. Declarations, such
+as a function signature or a structure's name, must always be visible but may
+be repeated so they go in headers. Definitions, such as function bodies and a
+structure's layout, don't have to be visible on use but must occur exactly
+once and go into source files.
+initialized with a @sizeof@ expression, the @align@ field is the type's
+alignment and uses an @alignof@ expression. The remaining fields are resolved
+to a name matching the field's name and type using the normal visibility and
+overload resolution rules of the type system.
+These operations are split up into several groups depending on where they take
+place which varies for monomorphic and polymorphic types. The first devision is
+between the declarations and the definitions. Declarations, such as a function
+signature or a aggregate's name, must always be visible but may be repeated in
+the form of forward declarations in headers. Definitions, such as function
+bodies and a aggregate's layout, can be separately compiled but must occur
+exactly once in a source file.
+\begin{sloppypar}
 The declarations include the virtual type definition and forward declarations
 of the virtual table instance, constructor, message function and
 @get_exception_vtable@. The definition includes the storage and
+initialization of the virtual table instance and the bodies of the three
+functions.
+@get_exception_vtable@. The definition includes the storage and initialization
+of the virtual table instance and the bodies of the three functions.
+\end{sloppypar}
 Monomorphic instances put all of these two groups in one place each.
 Polymorphic instances also split out the core declarations and definitions
 from the per-instance information. The virtual table type and most of the
+functions are polymorphic so they are all part of the core. The virtual table
+instance and the @get_exception_vtable@ function.
+Polymorphic instances also split out the core declarations and definitions from
+the per-instance information. The virtual table type and most of the functions
+are polymorphic so they are all part of the core. The virtual table instance
+and the @get_exception_vtable@ function.
+\begin{sloppypar}
 Coroutines and threads need instances of @CoroutineCancelled@ and
+@ThreadCancelled@ respectively to use all of their functionality.
+When a new data type is declared with @coroutine@ or @thread@
+the forward declaration for the instance is created as well. The definition
+of the virtual table is created at the definition of the main function.
+@ThreadCancelled@ respectively to use all of their functionality.  When a new
+data type is declared with @coroutine@ or @thread@ the forward declaration for
+the instance is created as well. The definition of the virtual table is created
+at the definition of the main function.
+\end{sloppypar}
 \subsection{Virtual Cast}
+Virtual casts are implemented as a function call that does the check and a
+old C-style cast to do the type conversion. The C-cast is just to make sure
+the generated code is correct so the rest of the section is about that
+function.
+The function is @__cfa__virtual_cast@ and it is implemented in the
+standard library. It takes a pointer to the target type's virtual table and
+the object pointer being cast. The function is very simple, getting the
+object's virtual table pointer and then checking to see if it or any of
+its ancestors, by using the parent pointers, are the same as the target type
+virtual table pointer. It does this in a simple loop.
+For the generated code a forward decaration of the virtual works as follows.
+There is a forward declaration of @__cfa__virtual_cast@ in every cfa
+file so it can just be used. The object argument is the expression being cast
+so that is just placed in the argument list.
+To build the target type parameter the compiler will create a mapping from
+concrete type-name -- so for polymorphic types the parameters are filled in
+-- to virtual table address. Every virtual table declaraction is added to the
+this table; repeats are ignored unless they have conflicting definitions.
+This does mean the declaractions have to be in scope, but they should usually
+be introduced as part of the type definition.
+Virtual casts are implemented as a function call that does the subtype check
+and a C coercion-cast to do the type conversion.
+% The C-cast is just to make sure the generated code is correct so the rest of
+% the section is about that function.
+The function is
+\begin{cfa}
+void * __cfa__virtual_cast( struct __cfa__parent_vtable const * parent,
+        struct __cfa__parent_vtable const * const * child );
+}
+\end{cfa}
+and it is implemented in the standard library. It takes a pointer to the target
+type's virtual table and the object pointer being cast. The function performs a
+linear search starting at the object's virtual-table and walking through the
+the parent pointers, checking to if it or any of its ancestors are the same as
+the target-type virtual table-pointer.
+For the generated code, a forward declaration of the virtual works as follows.
+There is a forward declaration of @__cfa__virtual_cast@ in every \CFA file so
+it can just be used. The object argument is the expression being cast so that
+is just placed in the argument list.
+To build the target type parameter, the compiler creates a mapping from
+concrete type-name -- so for polymorphic types the parameters are filled in --
+to virtual table address. Every virtual table declaration is added to the this
+table; repeats are ignored unless they have conflicting definitions.  Note,
+these declarations do not have to be in scope, but they should usually be
+introduced as part of the type definition.
+\PAB{I do not understood all of \VRef{s:VirtualSystem}. I think you need to
+write more to make it clear.}
 \section{Exceptions}
 …
 % resumption doesn't as well.
+Many modern languages work with an interal stack that function push and pop
+their local data to. Stack unwinding removes large sections of the stack,
+often across functions.
+At a very basic level this can be done with @setjmp@ \& @longjmp@
+which simply move the top of the stack, discarding everything on the stack
+above a certain point. However this ignores all the clean-up code that should
+be run when certain sections of the stack are removed (for \CFA these are from
+destructors and finally clauses) and also requires that the point to which the
+stack is being unwound is known ahead of time. libunwind is used to address
+both of these problems.
+Libunwind, provided in @unwind.h@ on most platorms, is a C library
+that provides \CPP style stack unwinding. Its operation is divided into two
+phases. The search phase -- phase 1 -- is used to scan the stack and decide
+where the unwinding will stop, this allows for a dynamic target. The clean-up
+phase -- phase 2 -- does the actual unwinding and also runs any clean-up code
+as it goes.
+To use the libunwind each function must have a personality function and an
+LSDA (Language Specific Data Area). Libunwind actually does very little, it
+simply moves down the stack from function to function. Most of the actions are
+implemented by the personality function which libunwind calls on every
+function. Since this is shared across many functions or even every function in
+a language it will need a bit more information. This is provided by the LSDA
+which has the unique information for each function.
+Theoretically the LSDA can contain anything but conventionally it is a table
+with entries reperenting areas of the function and what has to be done there
+during unwinding. These areas are described in terms of where the instruction
+pointer is. If the current value of the instruction pointer is between two
+values reperenting the beginning and end of a region then execution is
+currently being executed. These are used to mark out try blocks and the
+scopes of objects with destructors to run.
+GCC will generate an LSDA and attach its personality function with the
+@-fexceptions@ flag. However this only handles the cleanup attribute.
+This attribute is used on a variable and specifies a function that should be
+run when the variable goes out of scope. The function is passed a pointer to
+the object as well so it can be used to mimic destructors. It however cannot
+be used to mimic try statements.
+\subsection{Implementing Personality Functions}
+Personality functions have a complex interface specified by libunwind.
+This section will cover some of the important parts of that interface.
+\begin{lstlisting}
+typedef _Unwind_Reason_Code (*_Unwind_Personality_Fn)(
+    int version,
+    _Unwind_Action action,
+    _Unwind_Exception_Class exception_class,
+    _Unwind_Exception * exception,
+    struct _Unwind_Context * context);
+% Many modern languages work with an interal stack that function push and pop
+% their local data to. Stack unwinding removes large sections of the stack,
+% often across functions.
+Stack unwinding is the process of removing stack frames (activations) from the
+stack. On function entry and return, unwinding is handled directly by the code
+embedded in the function. Usually, the stack-frame size is known statically
+based on parameter and local variable declarations.  For dynamically-sized
+local variables, a runtime computation is necessary to know the frame
+size. Finally, a function's frame-size may change during execution as local
+variables (static or dynamic sized) go in and out of scope.
+Allocating/deallocating stack space is usually an $O(1)$ operation achieved by
+bumping the hardware stack-pointer up or down as needed.
+Unwinding across multiple stack frames is more complex because individual stack
+management code associated with each frame is bypassed. That is, the location
+of a function's frame-management code is largely unknown and dispersed
+throughout the function, hence the current frame size managed by that code is
+also unknown. Hence, code unwinding across frames does not have direct
+knowledge about what is on the stack, and hence, how much of the stack needs to
+be removed.
+% At a very basic level this can be done with @setjmp@ \& @longjmp@ which simply
+% move the top of the stack, discarding everything on the stack above a certain
+% point. However this ignores all the cleanup code that should be run when
+% certain sections of the stack are removed (for \CFA these are from destructors
+% and finally clauses) and also requires that the point to which the stack is
+% being unwound is known ahead of time. libunwind is used to address both of
+% these problems.
+The traditional unwinding mechanism for C is implemented by saving a snap-shot
+of a function's state with @setjmp@ and restoring that snap-shot with
+@longjmp@. This approach bypasses the need to know stack details by simply
+reseting to a snap-shot of an arbitrary but existing function frame on the
+stack. It is up to the programmer to ensure the snap-shot is valid when it is
+reset, making this unwinding approach fragile with potential errors that are
+difficult to debug because the stack becomes corrupted.
+However, many languages define cleanup actions that must be taken when objects
+are deallocated from the stack or blocks end, such as running a variable's
+destructor or a @try@ statement's @finally@ clause. Handling these mechanisms
+requires walking the stack and checking each stack frame for these potential
+actions.
+For exceptions, it must be possible to walk the stack frames in search of @try@
+statements to match and execute a handler. For termination exceptions, it must
+also be possible to unwind all stack frames from the throw to the matching
+catch, and each of these frames must be checked for cleanup actions. Stack
+walking is where most of the complexity and expense of exception handling
+appears.
+One of the most popular tools for stack management is libunwind, a low-level
+library that provides tools for stack walking, handler execution, and
+unwinding. What follows is an overview of all the relevant features of
+libunwind needed for this work, and how \CFA uses them to implement exception
+handling.
+\subsection{libunwind Usage}
+Libunwind, accessed through @unwind.h@ on most platforms, is a C library that
+provides \CC-style stack-unwinding. Its operation is divided into two phases:
+search and cleanup. The dynamic target search -- phase 1 -- is used to scan the
+stack and decide where unwinding should stop (but no unwinding occurs). The
+cleanup -- phase 2 -- does the unwinding and also runs any cleanup code.
+To use libunwind, each function must have a personality function and a Language
+Specific Data Area (LSDA).  The LSDA has the unique information for each
+function to tell the personality function where a function is executing, its
+current stack frame, and what handlers should be checked.  Theoretically, the
+LSDA can contain any information but conventionally it is a table with entries
+representing regions of the function and what has to be done there during
+unwinding. These regions are bracketed by the instruction pointer. If the
+instruction pointer is within a region's start/end, then execution is currently
+executing in that region. Regions are used to mark out the scopes of objects
+with destructors and try blocks.
+% Libunwind actually does very little, it simply moves down the stack from
+% function to function. Most of the actions are implemented by the personality
+% function which libunwind calls on every function. Since this is shared across
+% many functions or even every function in a language it will need a bit more
+% information.
+The GCC compilation flag @-fexceptions@ causes the generation of an LSDA and
+attaches its personality function. \PAB{to what is it attached?}  However, this
+flag only handles the cleanup attribute
+\begin{cfa}
+void clean_up( int * var ) { ... }
+int avar __attribute__(( __cleanup(clean_up) ));
+\end{cfa}
+which is used on a variable and specifies a function, \eg @clean_up@, run when
+the variable goes out of scope. The function is passed a pointer to the object
+so it can be used to mimic destructors. However, this feature cannot be used to
+mimic @try@ statements.
+\subsection{Personality Functions}
+Personality functions have a complex interface specified by libunwind.  This
+section covers some of the important parts of the interface.
+A personality function performs four tasks, although not all have to be
+present.
+\begin{lstlisting}[language=C,{moredelim=**[is][\color{red}]{@}{@}}]
+typedef _Unwind_Reason_Code (*@_Unwind_Personality_Fn@) (
+        _Unwind_Action @action@,
+        _Unwind_Exception_Class @exception_class@,
+        _Unwind_Exception * @exception@,
+        struct _Unwind_Context * @context@
+);
 \end{lstlisting}
+The return value, the reason code, is an enumeration of possible messages
+The @action@ argument is a bitmask of possible actions:
+\begin{enumerate}
+\item
+@_UA_SEARCH_PHASE@ specifies a search phase and tells the personality function
+to check for handlers.  If there is a handler in a stack frame, as defined by
+the language, the personality function returns @_URC_HANDLER_FOUND@; otherwise
+it return @_URC_CONTINUE_UNWIND@.
+\item
+@_UA_CLEANUP_PHASE@ specifies a cleanup phase, where the entire frame is
+unwound and all cleanup code is run. The personality function does whatever
+cleanup the language defines (such as running destructors/finalizers) and then
+generally returns @_URC_CONTINUE_UNWIND@.
+\item
+\begin{sloppypar}
+@_UA_HANDLER_FRAME@ specifies a cleanup phase on a function frame that found a
+handler. The personality function must prepare to return to normal code
+execution and return @_URC_INSTALL_CONTEXT@.
+\end{sloppypar}
+\item
+@_UA_FORCE_UNWIND@ specifies a forced unwind call. Forced unwind only performs
+the cleanup phase and uses a different means to decide when to stop
+\see{\VRef{s:ForcedUnwind}}.
+\end{enumerate}
+The @exception_class@ argument is a copy of the
+\lstinline[language=C]|exception|'s @exception_class@ field.
+The \lstinline[language=C]|exception| argument is a pointer to the user
+provided storage object. It has two public fields, the exception class, which
+is actually just a number, identifying the exception handling mechanism that
+created it, and the cleanup function. The cleanup function is called if
+required by the exception.
+The @context@ argument is a pointer to an opaque type passed to helper
+functions called inside the personality function.
+The return value, @_Unwind_Reason_Code@, is an enumeration of possible messages
 that can be passed several places in libunwind. It includes a number of
 messages for special cases (some of which should never be used by the
 …
 personality function should always return @_URC_CONTINUE_UNWIND@.
-The @version@ argument is the verson of the implementation that is
-calling the personality function. At this point it appears to always be 1 and
-it will likely stay that way until a new version of the API is updated.
-The @action@ argument is set of flags that tell the personality
-function when it is being called and what it must do on this invocation.
-The flags are as follows:
-\begin{itemize}
-\item@_UA_SEARCH_PHASE@: This flag is set whenever the personality
-function is called during the search phase. The personality function should
-decide if unwinding will stop in this function or not. If it does then the
-personality function should return @_URC_HANDLER_FOUND@.
-\item@_UA_CLEANUP_PHASE@: This flag is set whenever the personality
-function is called during the cleanup phase. If no other flags are set this
-means the entire frame will be unwound and all cleanup code should be run.
-\item@_UA_HANDLER_FRAME@: This flag is set during the cleanup phase
-on the function frame that found the handler. The personality function must
-prepare to return to normal code execution and return
-@_URC_INSTALL_CONTEXT@.
-\item@_UA_FORCE_UNWIND@: This flag is set if the personality function
-is called through a forced unwind call. Forced unwind only performs the
-cleanup phase and uses a different means to decide when to stop. See its
-section below.
-\end{itemize}
-The @exception_class@ argument is a copy of the @exception@'s
-@exception_class@ field.
-The @exception@ argument is a pointer to the user provided storage
-object. It has two public fields, the exception class which is actually just
-a number that identifies the exception handling mechanism that created it and
-the other is the clean-up function. The clean-up function is called if the
-exception needs to
-The @context@ argument is a pointer to an opaque type. This is passed
-to the many helper functions that can be called inside the personality
-function.
 \subsection{Raise Exception}
+This could be considered the central function of libunwind. It preforms the
+two staged unwinding the library is built around and most of the rest of the
+interface of libunwind is here to support it. It's signature is as follows:
+\begin{lstlisting}
+Raising an exception is the central function of libunwind and it performs a
+two-staged unwinding.
+\begin{cfa}
 _Unwind_Reason_Code _Unwind_RaiseException(_Unwind_Exception *);
+\end{cfa}
+First, the function begins the search phase, calling the personality function
+of the most recent stack frame. It continues to call personality functions
+traversing the stack from newest to oldest until a function finds a handler or
+the end of the stack is reached. In the latter case, raise exception returns
+@_URC_END_OF_STACK@.
+Second, when a handler is matched, raise exception continues onto the cleanup phase.
+Once again, it calls the personality functions of each stack frame from newest
+to oldest. This pass stops at the stack frame containing the matching handler.
+If that personality function has not install a handler, it is an error.
+If an error is encountered, raise exception returns either
+@_URC_FATAL_PHASE1_ERROR@ or @_URC_FATAL_PHASE2_ERROR@ depending on when the
+error occurred.
+\subsection{Forced Unwind}
+\label{s:ForcedUnwind}
+Forced Unwind is the other central function in libunwind.
+\begin{cfa}
+_Unwind_Reason_Code _Unwind_ForcedUnwind( _Unwind_Exception *,
+        _Unwind_Stop_Fn, void *);
+\end{cfa}
+It also unwinds the stack but it does not use the search phase. Instead another
+function, the stop function, is used to stop searching.  The exception is the
+same as the one passed to raise exception. The extra arguments are the stop
+function and the stop parameter. The stop function has a similar interface as a
+personality function, except it is also passed the stop parameter.
+\begin{lstlisting}[language=C,{moredelim=**[is][\color{red}]{@}{@}}]
+typedef _Unwind_Reason_Code (*@_Unwind_Stop_Fn@)(
+        _Unwind_Action @action@,
+        _Unwind_Exception_Class @exception_class@,
+        _Unwind_Exception * @exception@,
+        struct _Unwind_Context * @context@,
+        void * @stop_parameter@);
 \end{lstlisting}
-When called the function begins the search phase, calling the personality
-function of the most recent stack frame. It will continue to call personality
-functions traversing the stack new-to-old until a function finds a handler or
-the end of the stack is reached. In the latter case raise exception will
-return with @_URC_END_OF_STACK@.
-Once a handler has been found raise exception continues onto the the cleanup
-phase. Once again it will call the personality functins of each stack frame
-from newest to oldest. This pass will stop at the stack frame that found the
-handler last time, if that personality function does not install the handler
-it is an error.
-If an error is encountered raise exception will return either
-@_URC_FATAL_PHASE1_ERROR@ or @_URC_FATAL_PHASE2_ERROR@ depending
-on when the error occured.
-\subsection{Forced Unwind}
-This is the second big function in libunwind. It also unwinds a stack but it
-does not use the search phase. Instead another function, the stop function,
-is used to decide when to stop.
-\begin{lstlisting}
-_Unwind_Reason_Code _Unwind_ForcedUnwind(
-    _Unwind_Exception *, _Unwind_Stop_Fn, void *);
-\end{lstlisting}
-The exception is the same as the one passed to raise exception. The extra
-arguments are the stop function and the stop parameter. The stop function has
-a similar interface as a personality function, except it is also passed the
-stop parameter.
-\begin{lstlisting}
-typedef _Unwind_Reason_Code (*_Unwind_Stop_Fn)(
-    int version,
-    _Unwind_Action action,
-    _Unwind_Exception_Class exception_class,
-    _Unwind_Exception * exception,
-    struct _Unwind_Context * context,
-    void * stop_parameter);
-\end{lstlisting}
 The stop function is called at every stack frame before the personality
+function is called and then once more once after all frames of the stack have
+been unwound.
+Each time it is called the stop function should return @_URC_NO_REASON@
+or transfer control directly to other code outside of libunwind. The
+framework does not provide any assistance here.
+Its arguments are the same as the paired personality function.
+The actions @_UA_CLEANUP_PHASE@ and @_UA_FORCE_UNWIND@ are always
+set when it is called. By the official standard that is all but both GCC and
+Clang add an extra action on the last call at the end of the stack:
+@_UA_END_OF_STACK@.
+function is called and then once more after all frames of the stack are
+unwound.
+Each time it is called, the stop function should return @_URC_NO_REASON@ or
+transfer control directly to other code outside of libunwind. The framework
+does not provide any assistance here.
+\begin{sloppypar}
+Its arguments are the same as the paired personality function.  The actions
+@_UA_CLEANUP_PHASE@ and @_UA_FORCE_UNWIND@ are always set when it is
+called. Beyond the libunwind standard, both GCC and Clang add an extra action
+on the last call at the end of the stack: @_UA_END_OF_STACK@.
+\end{sloppypar}
 \section{Exception Context}
 % Should I have another independent section?
 % There are only two things in it, top_resume and current_exception. How it is
+% stored changes depending on wheither or not the thread-library is linked.
+The exception context is a piece of global storage used to maintain data
+across different exception operations and to communicate between different
+components.
+Each stack has its own exception context. In a purely sequental program, using
+only core Cforall, there is only one stack and the context is global. However
+if the library @libcfathread@ is linked then there can be multiple
+stacks so they will each need their own.
+To handle this code always gets the exception context from the function
+@this_exception_context@. The main exception handling code is in
+@libcfa@ and that library also defines the function as a weak symbol
+so it acts as a default. Meanwhile in @libcfathread@ the function is
+defined as a strong symbol that replaces it when the libraries are linked
+together.
+The version of the function defined in @libcfa@ is very simple. It
+returns a pointer to a global static variable. With only one stack this
+global instance is associated with the only stack.
+The version of the function defined in @libcfathread@ has to handle
+more as there are multiple stacks. The exception context is included as
+part of the per-stack data stored as part of coroutines. In the cold data
+section, stored at the base of each stack, is the exception context for that
+stack. The @this_exception_context@ uses the concurrency library to get
+the current coroutine and through it the cold data section and the exception
+context.
+% stored changes depending on whether or not the thread-library is linked.
+The exception context is global storage used to maintain data across different
+exception operations and to communicate among different components.
+Each stack must have its own exception context. In a sequential \CFA program,
+there is only one stack with a single global exception-context. However, when
+the library @libcfathread@ is linked, there are multiple stacks where each
+needs its own exception context.
+General access to the exception context is provided by function
+@this_exception_context@. For sequential execution, this function is defined as
+a weak symbol in the \CFA system-library, @libcfa@. When a \CFA program is
+concurrent, it links with @libcfathread@, where this function is defined with a
+strong symbol replacing the sequential version.
+% The version of the function defined in @libcfa@ is very simple. It returns a
+% pointer to a global static variable. With only one stack this global instance
+% is associated with the only stack.
+For coroutines, @this_exception_context@ accesses the exception context stored
+at the base of the stack. For threads, @this_exception_context@ uses the
+concurrency library to access the current stack of the thread or coroutine
+being executed by the thread, and then accesses the exception context stored at
+the base of this stack.
 \section{Termination}
 …
 % catches. Talk about GCC nested functions.
 Termination exceptions use libunwind quite heavily because it matches the
+intended use from \CPP exceptions very closely. The main complication is that
+since the \CFA compiler works by translating to C code it cannot generate the
 assembly to form the LSDA for try blocks or destructors.
+Termination exceptions use libunwind heavily because it matches the intended
+use from \CC exceptions closely. The main complication for \CFA is that the
+compiler generates C code, making it very difficult to generate the assembly to
+form the LSDA for try blocks or destructors.
 \subsection{Memory Management}
 The first step of termination is to copy the exception into memory managed by
+the exception system. Currently the system just uses malloc, without reserved
+memory or and ``small allocation" optimizations. The exception handling
 mechanism manages memory for the exception as well as memory for libunwind
 and the system's own per-exception storage.
 Exceptions are stored in variable sized block. The first component is a fixed
 sized data structure that contains the information for libunwind and the
+exception system. The second component is a blob of memory that is big enough
+to store the exception. Macros with pointer arthritic and type cast are
 used to move between the components or go from the embedded
+The first step of a termination raise is to copy the exception into memory
+managed by the exception system. Currently, the system uses @malloc@, rather
+than reserved memory or the stack top. The exception handling mechanism manages
+memory for the exception as well as memory for libunwind and the system's own
+per-exception storage.
+Exceptions are stored in variable-sized blocks. \PAB{Show a memory layout
+figure.} The first component is a fixed sized data structure that contains the
+information for libunwind and the exception system. The second component is an
+area of memory big enough to store the exception. Macros with pointer arthritic
+and type cast are used to move between the components or go from the embedded
 @_Unwind_Exception@ to the entire node.
+All of these nodes are strung together in a linked list. One linked list per
+stack, with the head stored in the exception context. Within each linked list
+the most recently thrown exception is at the head and the older exceptions
+are further down the list. This list format allows exceptions to be thrown
+while a different exception is being handled. Only the exception at the head
+of the list is currently being handled, the other will wait for the
+exceptions before them to be removed.
+The virtual members in the exception's virtual table. The size of the
+exception, the copy function and the free function are all in the virtual
+table so they are decided per-exception type. The size and copy function are
+used right away when the exception is copied in to managed memory. After the
+exception is handled the free function is used to clean up the exception and
+then the entire node is passed to free.
+\subsection{Try Statements \& Catch Clauses}
+The try statements with termination handlers have a pretty complex conversion
+to compensate for the lack of assembly generation. Libunwind requires an LSDA
+(Language Specific Data Area) and personality function for a function to
+unwind across it. The LSDA in particular is hard to generate at the level of
+C which is what the \CFA compiler outputs so a work-around is used.
+This work around is a function called @__cfaehm_try_terminate@ in the
+standard library. The contents of a try block and the termination handlers
+are converted into functions. These are then passed to the try terminate
+function and it calls them. This puts the try statements in their own
+functions so that no function has to deal with both termination handlers and
+destructors.
+This function has some custom embedded assembly that defines its personality
+function and LSDA. This is hand coded in C which is why there is only one
+version of it, the compiler has no capability to generate it. The personality
+function is structured so that it may be expanded, but really it only handles
+this one function. Notably it does not handle any destructors so the function
+is constructed so that it does need to run it.
+All of these nodes are linked together in a list, one list per stack, with the
+list head stored in the exception context. Within each linked list, the most
+recently thrown exception is at the head followed by older thrown
+exceptions. This format allows exceptions to be thrown, while a different
+exception is being handled. The exception at the head of the list is currently
+being handled, while other exceptions wait for the exceptions before them to be
+removed.
+The virtual members in the exception's virtual table provide the size of the
+exception, the copy function, and the free function, so they are specific to an
+exception type. The size and copy function are used immediately to copy an
+exception into managed memory. After the exception is handled the free function
+is used to clean up the exception and then the entire node is passed to free.
+\subsection{Try Statements and Catch Clauses}
+The try statement with termination handlers is complex because it must
+compensate for the lack of assembly-code generated from \CFA. Libunwind
+requires an LSDA and personality function for control to unwind across a
+function. The LSDA in particular is hard to mimic in generated C code.
+The workaround is a function called @__cfaehm_try_terminate@ in the standard
+library. The contents of a try block and the termination handlers are converted
+into functions. These are then passed to the try terminate function and it
+calls them. This approach puts a try statement in its own functions so that no
+function has to deal with both termination handlers and destructors. \PAB{I do
+not understand the previous sentence.}
+This function has some custom embedded assembly that defines \emph{its}
+personality function and LSDA. The assembly is created with handcrafted C @asm@
+statements, which is why there is only one version of it. The personality
+function is structured so that it can be expanded, but currently it only
+handles this one function.  Notably, it does not handle any destructors so the
+function is constructed so that it does need to run it. \PAB{I do not
+understand the previous sentence.}
 The three functions passed to try terminate are:
 \begin{itemize}
 \item The try function: This function is the try block, all the code inside
 the try block is placed inside the try function. It takes no parameters and
+has no return value. This function is called during regular execution to run
 the try block.
+\item The match function: This function decides if this try statement should
+handle any given termination exception. It takes a pointer to the exception
+and returns 0 if the exception is not handled here. Otherwise the return value
+is the id of the handler that should handle the exception. It is called
+during the search phase.
+It is constructed from the conditional part of each handler. It runs each
+check in turn, first checking to see if the object
+\item The catch function: This function handles the exception. It takes a
+pointer to the exception and the handler's id and returns nothing. It is
+called after the clean-up phase.
+It is constructed by stitching together the bodies of each handler
+\end{itemize}
+All three are created with GCC nested functions. GCC nested functions can be
+used to create closures, functions that can refer to the state of other
+functions on the stack. This allows the functions to refer to the main
+function and all the variables in scope.
+These nested functions and all other functions besides
+@__cfaehm_try_terminate@ in \CFA use the GCC personality function and
+the @-fexceptions@ flag to generate the LSDA. This allows destructors
 to be implemented with the cleanup attribute.
+\begin{description}
+\item[try function:] This function is the try block, all the code inside the
+try block is placed inside the try function. It takes no parameters and has no
+return value. This function is called during regular execution to run the try
+block.
+\item[match function:] This function is called during the search phase and
+decides if a catch clause matches the termination exception.  It is constructed
+from the conditional part of each handler and runs each check, top to bottom,
+in turn, first checking to see if the exception type matches and then if the
+condition is true. It takes a pointer to the exception and returns 0 if the
+exception is not handled here. Otherwise the return value is the id of the
+handler that matches the exception.
+\item[handler function:] This function handles the exception. It takes a
+pointer to the exception and the handler's id and returns nothing. It is called
+after the cleanup phase.  It is constructed by stitching together the bodies of
+each handler and dispatches to the selected handler.
+\end{description}
+All three functions are created with GCC nested functions. GCC nested functions
+can be used to create closures, functions that can refer to the state of other
+functions on the stack. This approach allows the functions to refer to all the
+variables in scope for the function containing the @try@ statement.  These
+nested functions and all other functions besides @__cfaehm_try_terminate@ in
+\CFA use the GCC personality function and the @-fexceptions@ flag to generate
+the LSDA. This allows destructors to be implemented with the cleanup attribute.
 \section{Resumption}
 % The stack-local data, the linked list of nodes.
+Resumption uses a list of nodes for its stack traversal. The head of the list
+is stored in the exception context. The nodes in the list just have a pointer
+Resumption simple to implement because there is no stack unwinding. The
+resumption raise uses a list of nodes for its stack traversal. The head of the
+list is stored in the exception context. The nodes in the list have a pointer
 to the next node and a pointer to the handler function.
+The on a resumption throw the this list is traversed. At each node the
 handler function is called and is passed the exception by pointer. It returns
 true if the exception was handled and false otherwise.
 The handler function does both the matching and catching. It tries each
+the condition of @catchResume@ in order, top-to-bottom and until it
 finds a handler that matches. If no handler matches then the function returns
 false. Otherwise the matching handler is run, if it completes successfully
+the function returns true. Rethrows, through the @throwResume;@
 statement, cause the function to return true.
+A resumption raise traverses this list. At each node the handler function is
+called, passing the exception by pointer. It returns true if the exception is
+handled and false otherwise.
+The handler function does both the matching and handling. It computes the
+condition of each @catchResume@ in top-to-bottom order, until it finds a
+handler that matches. If no handler matches then the function returns
+false. Otherwise the matching handler is run; if it completes successfully, the
+function returns true. Reresume, through the @throwResume;@ statement, cause
+the function to return true.
 % Recursive Resumption Stuff:
+Blocking out part of the stack is accomplished by updating the front of the
+list as the search continues. Before the handler at a node is called the head
+of the list is updated to the next node of the current node. After the search
+is complete, successful or not, the head of the list is reset.
+This means the current handler and every handler that has already been
+checked are not on the list while a handler is run. If a resumption is thrown
+during the handling of another resumption the active handlers and all the
+other handler checked up to this point will not be checked again.
+Search skipping \see{\VPageref{p:searchskip}}, which ignores parts of the stack
+already examined, is accomplished by updating the front of the list as the
+search continues. Before the handler at a node is called the head of the list
+is updated to the next node of the current node. After the search is complete,
+successful or not, the head of the list is reset.
+This mechanism means the current handler and every handler that has already
+been checked are not on the list while a handler is run. If a resumption is
+thrown during the handling of another resumption the active handlers and all
+the other handler checked up to this point are not checked again.
 This structure also supports new handler added while the resumption is being
 handled. These are added to the front of the list, pointing back along the
+stack -- the first one will point over all the checked handlers -- and the
+ordering is maintained.
+\subsection{Libunwind Compatibility}
+Resumption does not use libunwind for two simple reasons. The first is that
+it does not have to unwind anything so would never need to use the clean-up
+phase. Still the search phase could be used to make it free to enter or exit
+a try statement with resumption handlers in the same way termination handlers
+are for the same trade off in the cost of the throw. This is where the second
+reason comes in, there is no way to return from a search without installing
+a handler or raising an error.
+Although work arounds could be created none seemed to be worth it for the
+prototype. This implementation has no difference in behaviour and is much
+simpler.
+stack -- the first one points over all the checked handlers -- and the ordering
+is maintained.
+\label{p:zero-cost}
+Note, the resumption implementation has a cost for entering/exiting a @try@
+statement with @catchResume@ clauses, whereas a @try@ statement with @catch@
+clauses has zero-cost entry/exit. While resumption does not need the stack
+unwinding and cleanup provided by libunwind, it could use the search phase to
+providing zero-cost enter/exit using the LSDA. Unfortunately, there is no way
+to return from a libunwind search without installing a handler or raising an
+error.  Although workarounds might be possible, they are beyond the scope of
+this thesis. The current resumption implementation has simplicity in its
+favour.
 % Seriously, just compare the size of the two chapters and then consider
 % that unwind is required knowledge for that chapter.
 …
 \section{Finally}
 % Uses destructors and GCC nested functions.
+Finally clauses are a simple decomposition to some of the existing features.
+The code in the block is placed into a GCC nested function with a unique name,
+no arguments or return values. This nested function is then set as the
+clean-up function of an empty object that is declared at the beginning of a
+block placed around the contexts of the try statement.
+Finally clauses is placed into a GCC nested-function with a unique name, and no
+arguments or return values. This nested function is then set as the cleanup
+function of an empty object that is declared at the beginning of a block placed
+around the context of the associated @try@ statement.
 The rest is handled by GCC. The try block and all handlers are inside the
 block. When they are complete control exits the block and the empty object
 is cleaned up, which runs the function that contains the finally code.
+block. At completion, control exits the block and the empty object is cleaned
+up, which runs the function that contains the finally code.
 \section{Cancellation}
 …
 Cancellation also uses libunwind to do its stack traversal and unwinding,
 however it uses a different primary function @_Unwind_ForcedUnwind@.
 Details of its interface can be found in the unwind section.
 The first step of cancellation is to find the stack was cancelled and which
 type of stack it is. Luckily the threads library stores the main thread
 pointer and the current thread pointer and every thread stores a pointer to
+however it uses a different primary function @_Unwind_ForcedUnwind@.  Details
+of its interface can be found in the \VRef{s:ForcedUnwind}.
+The first step of cancellation is to find the cancelled stack and its type:
+coroutine or thread. Fortunately, the thread library stores the main thread
+pointer and the current thread pointer, and every thread stores a pointer to
 its main coroutine and the coroutine it is currently executing.
+So if the the current thread's main and current coroutine do not match, it is
+a coroutine cancellation. Otherwise if the main and current thread do not
+match, it is a thread cancellation. Otherwise it is a main thread
+cancellation.
+However if the threading library is not linked then execution must be on the
+main stack as that is the only one that exists. So the entire check is skipped
+using the linker and weak symbols. Instead the main thread cancellation is
+unconditionally preformed.
+Regardless of how they are choosen afterwords the stop function and the stop
+parameter are passed to the forced unwind functon. The general pattern of all
+three stop functions is the same, they continue unwinding until the end of
+stack when they do there primary work.
+Main stack cancellation it is very simple. The ``transfer" is just an abort,
+the program stops executing.
+The coroutine cancellation stores the exception on the coroutine and then
+does a coroutine context switch. The rest is handled inside resume. Every time
+control returns from a resumed thread there is a check to see if it is
+cancelled. If it is the exception is retrieved and the CoroutineCancelled
+exception is constructed and loaded. It is then thrown as a regular exception
+with the default handler coming from the context of the resumption call.
+The thread cancellation stores the exception on the thread's main stack and
+then returns to the scheduler. The rest is handled by the joiner. The wait
+for the joined thread to finish works the same but after that it checks
+to see if there was a cancellation. If there was the exception is retrieved
+and the ThreadCancelled exception is constructed. The default handler is
+passed in as a function pointer. If it is null (as it is for the
+auto-generated joins on destructor call) it a default is used that simply
+calls abort; which gives the required handling on implicate join.
+The first check is if the current thread's main and current coroutine do not
+match, implying a coroutine cancellation; otherwise, it is a thread
+cancellation. Otherwise it is a main thread cancellation. \PAB{Previous
+sentence does not make sense.}
+However, if the threading library is not linked, the sequential execution is on
+the main stack. Hence, the entire check is skipped because the weak-symbol
+function is loaded. Therefore, a main thread cancellation is unconditionally
+performed.
+Regardless of how the stack is chosen, the stop function and parameter are
+passed to the forced-unwind function. The general pattern of all three stop
+functions is the same: they continue unwinding until the end of stack when they
+do there primary work.
+For main stack cancellation, the transfer is just a program abort.
+For coroutine cancellation, the exception is stored on the coroutine's stack,
+and the coroutine context switches to its last resumer. The rest is handled on
+the backside of the resume, which check if the resumed coroutine is
+cancelled. If cancelled, the exception is retrieved from the resumed coroutine,
+and a @CoroutineCancelled@ exception is constructed and loaded with the
+cancelled exception. It is then resumed as a regular exception with the default
+handler coming from the context of the resumption call.
+For thread cancellation, the exception is stored on the thread's main stack and
+then context switched to the scheduler. The rest is handled by the thread
+joiner. When the join is complete, the joiner checks if the joined thread is
+cancelled. If cancelled, the exception is retrieved and the joined thread, and
+a @ThreadCancelled@ exception is constructed and loaded with the cancelled
+exception. The default handler is passed in as a function pointer. If it is
+null (as it is for the auto-generated joins on destructor call), the default is
+used, which is a program abort.
+%; which gives the required handling on implicate join.

doc/theses/andrew_beach_MMath/unwinding.tex

-                      rcd70477
+                      rf99f5ba
 \chapter{Unwinding in \CFA}
+\chapter{\texorpdfstring{Unwinding in \CFA}{Unwinding in Cforall}}
+Stack unwinding is the process of removing things from the stack. Within
+functions and on function return this is handled directly by the code in the
+function itself as it knows exactly what is on the stack just from the
+current location in the function. Unwinding across stack frames means that it
+is no longer knows exactly what is on the stack or even how much of the stack
+needs to be removed.
+Stack unwinding is the process of removing stack frames (activations) from the
+stack. On function entry and return, unwinding is handled directly by the code
+embedded in the function. Usually, the stack-frame size is known statically
+based on parameters and local variable declarations.  For dynamically-sized
+local variables, a runtime computation is necessary to know the frame
+size. Finally, a function's frame-size may change during execution as local
+variables (static or dynamic sized) go in and out of scope.
+Allocating/deallocating stack space is usually an $O(1)$ operation achieved by
+bumping the hardware stack-pointer up or down as needed.
+Even this is fairly simple if nothing needs to happen when the stack unwinds.
+Traditional C can unwind the stack by saving and restoring state (with
+@setjmp@ \& @longjmp@). However many languages define actions that
+have to be taken when something is removed from the stack, such as running
+a variable's destructor or a @try@ statement's @finally@
+clause. Handling this requires walking the stack going through each stack
 frame.
+Unwinding across multiple stack frames is more complex because individual stack
+management code associated with each frame is bypassed. That is, the location
+of a function's frame code is largely unknown and dispersed throughout the
+function, hence the current stack-frame size managed by that code is also
+unknown. Hence, code unwinding across frames does not have direct knowledge
+about what is on the stack, and hence, how much of the stack needs to be
+removed.
+For exceptions, this means everything from the point the exception is raised
+to the point it is caught, while checking each frame for handlers during the
+stack walk to find out where it should be caught. This is where the most of
+the expense and complexity of exception handling comes from.
+The traditional unwinding mechanism for C is implemented by saving a snap-shot
+of a function's state with @setjmp@ and restoring that snap-shot with
+@longjmp@. This approach bypasses the need to know stack details by simply
+reseting to a snap-shot of an arbitrary but existing function frame on the
+stack. It is up to the programmer to ensure the snap-shot is valid when it is
+reset, making the code fragile with potential errors that are difficult to
+debug because the stack becomes corrupted.
+To do all of this we use libunwind, a low level library that provides tools
+for stack walking and stack unwinding. What follows is an overview of all the
+relivant features of libunwind and then how \CFA uses them to implement its
+exception handling.
+However, many languages define cleanup actions that have to be taken when
+something is deallocated from the stack or blocks end, such as running a
+variable's destructor or a @try@ statement's @finally@ clause. Handling these
+mechanisms requires walking the stack and checking each stack frame for these
+potential actions.
+For exceptions, it must be possible to walk the stack frames in search of try
+statements with handlers to perform exception matching. For termination
+exceptions, it must be possible to unwind all stack frames from the throw to
+the matching catch, and each of these frames must be checked for cleanup
+actions. Stack walking is where the most of the complexity and expense of
+exception handling comes from.
+One of the most popular tools for stack management is libunwind, a low level
+library that provides tools for stack walking and unwinding. What follows is an
+overview of all the relevant features of libunwind and how \CFA uses them to
+implement its exception handling.
 \section{libunwind Usage}
+\CFA uses two primary functions in libunwind to create most of its
+exceptional control-flow: @_Unwind_RaiseException@ and
+@_Unwind_ForcedUnwind@.
+Their operation is divided into two phases: search and clean-up. The search
+phase -- phase 1 -- is used to scan the stack but not unwinding it. The
+clean-up phase -- phase 2 -- is used for unwinding.
+\CFA uses two primary functions in libunwind to create most of its exceptional
+control-flow: @_Unwind_RaiseException@ and @_Unwind_ForcedUnwind@.  Their
+operation is divided into two phases: search and clean-up. The search phase --
+phase 1 -- is used to scan the stack but not unwinding it. The clean-up phase
+-- phase 2 -- is used for unwinding.
 The raise-exception function uses both phases. It starts by searching for a
 …
 A personality function performs three tasks, although not all have to be
 present. The tasks performed are decided by the actions provided.
 @_Unwind_Action@ is a bitmask of possible actions and an argument of
 this type is passed into the personality function.
+@_Unwind_Action@ is a bitmask of possible actions and an argument of this type
+is passed into the personality function.
 \begin{itemize}
+\item@_UA_SEARCH_PHASE@ is passed in search phase and tells the
+personality function to check for handlers. If there is a handler in this
+stack frame, as defined by the language, the personality function should
+return @_URC_HANDLER_FOUND@. Otherwise it should return
+@_URC_CONTINUE_UNWIND@.
+\item@_UA_CLEANUP_PHASE@ is passed in during the clean-up phase and
+means part or all of the stack frame is removed. The personality function
+should do whatever clean-up the language defines
+(such as running destructors/finalizers) and then generally returns
+@_URC_CONTINUE_UNWIND@.
+\item@_UA_HANDLER_FRAME@ means the personality function must install
+a handler. It is also passed in during the clean-up phase and is in addition
+to the clean-up action. libunwind provides several helpers for the personality
+function here. Once it is done, the personality function must return
+@_URC_INSTALL_CONTEXT@.
+\item
+\begin{sloppypar}
+@_UA_SEARCH_PHASE@ is passed in for the search phase and tells the personality
+function to check for handlers. If there is a handler in a stack frame, as
+defined by the language, the personality function returns @_URC_HANDLER_FOUND@;
+otherwise it return @_URC_CONTINUE_UNWIND@.
+\end{sloppypar}
+\item
+@_UA_CLEANUP_PHASE@ is passed in during the clean-up phase and means part or
+all of the stack frame is removed. The personality function does whatever
+clean-up the language defines (such as running destructors/finalizers) and then
+generally returns @_URC_CONTINUE_UNWIND@.
+\item
+@_UA_HANDLER_FRAME@ means the personality function must install a handler. It
+is also passed in during the clean-up phase and is in addition to the clean-up
+action. libunwind provides several helpers for the personality function. Once
+it is done, the personality function returns @_URC_INSTALL_CONTEXT@.
 \end{itemize}
 The personality function is given a number of other arguments. Some are for
 compatability and there is the @struct _Unwind_Context@ pointer which
 passed to many helpers to get information about the current stack frame.
+The personality function is given a number of other arguments. Some arguments
+are for compatibility, and there is the @struct _Unwind_Context@ pointer which
+is passed to many helpers to get information about the current stack frame.
+Forced-unwind only performs the clean-up phase. It takes three arguments:
+a pointer to the exception, a pointer to the stop function and a pointer to
+the stop parameter. It does most of the same things as phase two of
+raise-exception but with some extras.
+The first it passes in an extra action to the personality function on each
+stack frame, @_UA_FORCE_UNWIND@, which means a handler cannot be
+For cancellation, forced-unwind only performs the clean-up phase. It takes
+three arguments: a pointer to the exception, a pointer to the stop function and
+a pointer to the stop parameter. It does most of the same actions as phase two
+of raise-exception but passes in an extra action to the personality function on
+each stack frame, @_UA_FORCE_UNWIND@, which means a handler cannot be
 installed.
+The big change is that forced-unwind calls the stop function. Each time it
 steps into a frame, before calling the personality function, it calls the
 stop function. The stop function receives all the same arguments as the
 personality function will and the stop parameter supplied to forced-unwind.
+As well, forced-unwind calls the stop function each time it steps into a frame,
+before calling the personality function. The stop function receives all the
+same arguments as the personality function and the stop parameter supplied to
+forced-unwind.
 The stop function is called one more time at the end of the stack after all
 stack frames have been removed. By the standard API this is marked by setting
+stack frames have been removed. The standard API marks this frame by setting
 the stack pointer inside the context passed to the stop function. However both
 GCC and Clang add an extra action for this case @_UA_END_OF_STACK@.
+Each time function the stop function is called it can do one or two things.
+When it is not the end of the stack it can return @_URC_NO_REASON@ to
+continue unwinding.
+Each time the stop function is called, it can do one or two things.  When it is
+not the end of the stack it can return @_URC_NO_REASON@ to continue unwinding.
 % Is there a reason that NO_REASON is used instead of CONTINUE_UNWIND?
+Its only other option is to use its own means to transfer control elsewhere
+and never return to its caller. It may always do this and no additional tools
 are provided to do it.
+The other option is to use some other means to transfer control elsewhere and
+never return to its caller. libunwind provides no additional tools for
+alternate transfers of control.
 \section{\CFA Implementation}
+\section{\texorpdfstring{\CFA Implementation}{Cforall Implementation}}
 To use libunwind, \CFA provides several wrappers, its own storage,
 personality functions, and a stop function.
+To use libunwind, \CFA provides several wrappers, its own storage, personality
+functions, and a stop function.
 The wrappers perform three tasks: set-up, clean-up and controlling the
 …
 The core control code is called every time a throw -- after set-up -- or
 re-throw is run. It uses raise-exception to search for a handler and to run it
 if one is found. If no handler is found and raise-exception returns then
+if one is found. If no handler is found and raise-exception returns, then
 forced-unwind is called to run all destructors on the stack before terminating
 the process.
 The stop function is very simple. It checks the end of stack flag to see if
+it is finished unwinding. If so, it calls @exit@ to end the process,
 otherwise it returns with no-reason to continue unwinding.
+The stop function is simple. It checks for the end of stack flag to see if
+unwinding is finished. If so, it calls @exit@ to end the process, otherwise it
+returns with no-reason to continue unwinding.
 % Yeah, this is going to have to change.
 The personality routine is more complex because it has to obtain information
 about the function by scanning the LSDA (Language Specific Data Area). This
+about the function by scanning the Language Specific Data Area (LSDA). This
 step allows a single personality function to be used for multiple functions and
 let that personaliity function figure out exactly where in the function
 execution was, what is currently in the stack frame and what handlers should
 be checked.
+lets that personality function figure out exactly where in the function
+execution is, what is currently in the stack frame, and what handlers should be
+checked.
 % Not that we do that yet.
+However, generating the LSDA is difficult. It requires knowledge about the
 location of the instruction pointer and stack layout, which varies with
+compiler and optimization levels. So for frames where there are only
+destructors, GCC's attribute cleanup with the @-fexception@ flag is
 sufficient to handle unwinding.
+It is also necessary to generate the LSDA, which is difficult. It requires
+knowledge about the location of the instruction pointer and stack layout, which
+varies with compiler and optimization levels. Fortunately, for frames where
+there are only destructors, GCC's attribute cleanup with the @-fexception@ flag
+is sufficient to handle unwinding.
 The only functions that require more than that are those that contain
+@try@ statements. A @try@ statement has a @try@
+clause, some number of @catch@ clauses and @catchResume@
 clauses and may have a @finally@ clause. Of these only @try@
+statements with @catch@ clauses need to be transformed and only they
 and the @try@ clause are involved.
+The only functions that require more information are those containing @try@
+statements. Specifically, only @try@ statements with @catch@ clauses need to be
+transformed.  The @try@ statement is converted into a series of closures that
+can access other parts of the function according to scoping rules but can be
+passed around. The @catch@ clauses are converted into two functions: the match
+function and the handler function.
+The @try@ statement is converted into a series of closures which can
+access other parts of the function according to scoping rules but can be
+passed around. The @try@ clause is converted into the try functions,
+almost entirely unchanged. The @catch@ clauses are converted into two
+functions; the match function and the catch function.
+Together the match function and the catch function form the code that runs when
+an exception passes out of the guarded block for a try statement. The match
+function is used during the search phase: it is passed an exception and checks
+each handler to see if the raised exception matches the handler exception. It
+returns an index that represents which handler matched or there is no
+match. The catch function is used during the clean-up phase, it is passed an
+exception and the index of a handler. It casts the exception to the exception
+type declared in that handler and then runs the handler's body.
+Together the match function and the catch function form the code that runs
+when an exception passes out of a try block. The match function is used during
+the search phase, it is passed an exception and checks each handler to see if
+it will handle the exception. It returns an index that repersents which
+handler matched or that none of them did. The catch function is used during
+the clean-up phase, it is passed an exception and the index of a handler. It
+casts the exception to the exception type declared in that handler and then
+runs the handler's body.
+These three functions are passed to @try_terminate@. This is an
+These three functions are passed to @try_terminate@, which is an
 % Maybe I shouldn't quote that, it isn't its actual name.
 internal hand-written function that has its own personality function and
 custom assembly LSD does the exception handling in \CFA. During normal
 execution all this function does is call the try function and then return.
 It is only when exceptions are thrown that anything interesting happens.
+internal hand-written function that has its own personality function and custom
+assembly LSDA for doing the exception handling in \CFA. During normal
+execution, this function calls the try function and then return.  It is only
+when exceptions are thrown that anything interesting happens.
 During the search phase the personality function gets the pointer to the match
 function and calls it. If the match function returns a handler index the
+function and calls it. If the match function returns a handler index, the
 personality function saves it and reports that the handler has been found,
 otherwise unwinding continues.
+During the clean-up phase the personality function only does anything if the
+handler was found in this frame. If it was then the personality function
 installs the handler, which is setting the instruction pointer in
+@try_terminate@ to an otherwise unused section that calls the catch
+function, passing it the current exception and handler index.
 @try_terminate@ returns as soon as the catch function returns.
+otherwise unwinding continues.  During the clean-up phase, the personality
+function only performs an action, when a handler is found in a frame. For each
+found frame, the personality function installs the handler, which sets the
+instruction pointer in @try_terminate@ to an otherwise unused section that
+calls the catch function, passing it the current exception and handler index.
+@try_terminate@ returns as soon as the catch function returns.  At this point
+control has returned to normal control flow.
+At this point control has returned to normal control flow.
+\PAB{Maybe a diagram would be helpful?}

doc/theses/andrew_beach_MMath/uw-ethesis.tex

-                      rcd70477
+                      rf99f5ba
 \hypersetup{
     plainpages=false,       % needed if Roman numbers in frontpages
     unicode=false,          % non-Latin characters in Acrobat’s bookmarks
     pdftoolbar=true,        % show Acrobat’s toolbar?
     pdfmenubar=true,        % show Acrobat’s menu?
+    unicode=false,          % non-Latin characters in Acrobat's bookmarks
+    pdftoolbar=true,        % show Acrobat's toolbar?
+    pdfmenubar=true,        % show Acrobat's menu?
     pdffitwindow=false,     % window fit to page when opened
     pdfstartview={FitH},    % fits the width of the page to the window
 …
 \input{common}
 \CFAStyle                                               % CFA code-style for all languages
+\lstset{basicstyle=\linespread{0.9}\tt}
+\lstset{language=CFA,basicstyle=\linespread{0.9}\tt}    % CFA default lnaguage
+\newcommand{\PAB}[1]{{\color{blue}PAB: #1}}
 %======================================================================
 …
 \input{existing}
 \input{features}
+\input{unwinding}
+\input{implement}
+%\input{unwinding}
 \input{future}

libcfa/src/Makefile.am

rcd70477	rf99f5ba
76	76	stdlib.hfa \
77	77	time.hfa \
	78	bits/weakso_locks.hfa \
78	79	containers/maybe.hfa \
79	80	containers/pair.hfa \

libcfa/src/bits/collection.hfa

-                      rcd70477
+                      rf99f5ba
+//
+// Cforall Version 1.0.0 Copyright (C) 2021 University of Waterloo
+//
+// The contents of this file are covered under the licence agreement in the
+// file "LICENCE" distributed with Cforall.
+//
+// bits/collection.hfa -- PUBLIC
+// Intrusive singly-linked list
+//
+// Author           : Colby Alexander Parsons & Peter A. Buhr
+// Created On       : Thu Jan 21 19:46:50 2021
+// Last Modified By :
+// Last Modified On :
+// Update Count     :
+//
 #pragma once
-#include <stdio.h> // REMOVE THIS AFTER DEBUGGING
 struct Colable {
         struct Colable * next;                                                                          // next node in the list
+        // next node in the list
         // invariant: (next != 0) <=> listed()
+        struct Colable * next;
 };
 #ifdef __cforall
 …
         Collection & ?=?( const Collection & ) = void;          // no assignment
         void ?{}( Collection & collection ) with( collection ) {
+        void ?{}( Collection & collection ) with( collection ) {
                 root = 0p;
         } // post: empty()

libcfa/src/bits/sequence.hfa

-                      rcd70477
+                      rf99f5ba
+//
+// Cforall Version 1.0.0 Copyright (C) 2021 University of Waterloo
+//
+// The contents of this file are covered under the licence agreement in the
+// file "LICENCE" distributed with Cforall.
+//
+// bits/sequence.hfa -- PUBLIC
+// Intrusive doubly-linked list
+//
+// Author           : Colby Alexander Parsons & Peter A. Buhr
+// Created On       : Thu Jan 21 19:46:50 2021
+// Last Modified By :
+// Last Modified On :
+// Update Count     :
+//
 #pragma once
 …
 struct Seqable {
         __cfa_anonymous_object(Colable);
+        struct Seqable * back;                                                                          // pointer to previous node in the list
+        // pointer to previous node in the list
+        struct Seqable * back;
 };
 …
                 return sq->back;
+        }
-        // // wrappers to make Collection have T
-        // forall( T & ) {
-        //      T *& Back( T * n ) {
-        //              return (T *)Back( (Seqable *)n );
-        //      }
-        // } // distribution
 } // distribution
 …
 // and the back field of the last node points at the first node (circular).
 forall( T & | { T *& Back ( T * ); T *& Next ( T * ); } ) {
+forall( T & ) {
         struct Sequence {
+                inline Collection;                                                              // Plan 9 inheritance
+                // Plan 9 inheritance
+                inline Collection;
         };
         static inline {
+                void ?{}( Sequence(T) &, const Sequence(T) & ) = void; // no copy
+                Sequence(T) & ?=?( const Sequence(T) & ) = void; // no assignment
+                void ?{}( Sequence(T) & s ) with( s ) {
+                        ((Collection &)s){};
+                }       // post: isEmpty()
+        }
+        static inline forall(| { T *& Back ( T * ); T *& Next ( T * ); }) {
                 // wrappers to make Collection have T
                 T & head( Sequence(T) & s ) with( s ) {
                         return *(T *)head( (Collection &)s );
                 } // post: empty() & head() == 0 | !empty() & head() in *s
-                void ?{}( Sequence(T) &, const Sequence(T) & ) = void; // no copy
-                Sequence(T) & ?=?( const Sequence(T) & ) = void; // no assignment
-                void ?{}( Sequence(T) & s ) with( s ) {
-                        ((Collection &)s){};
-                }       // post: isEmpty()
                 // Return a pointer to the last sequence element, without removing it.
 …
                         return n;
                 } // post: n->listed() & *n in *s & succ(n) == bef
                 // pre: n->listed() & *n in *s
                 T & remove( Sequence(T) & s, T & n ) with( s ) { // O(1)
 …
         static inline {
                 void ?{}( SeqIterRev(T) & si ) with( si ) {
+                void ?{}( SeqIterRev(T) & si ) with( si ) {
                         ((ColIter &)si){};
                         seq = 0p;
 …
                 // Create a iterator active in sequence s.
                 void ?{}( SeqIterRev(T) & si, Sequence(T) & s ) with( si ) {
+                void ?{}( SeqIterRev(T) & si, Sequence(T) & s ) with( si ) {
                         ((ColIter &)si){};
                         seq = &s;
 …
                 } // post: elts = null
                 void ?{}( SeqIterRev(T) & si, Sequence(T) & s, T & start ) with( si ) {
+                void ?{}( SeqIterRev(T) & si, Sequence(T) & s, T & start ) with( si ) {
                         ((ColIter &)si){};
                         seq = &s;

libcfa/src/concurrency/locks.cfa

-                      rcd70477
+                      rf99f5ba
+//
+// Cforall Version 1.0.0 Copyright (C) 2021 University of Waterloo
+//
+// The contents of this file are covered under the licence agreement in the
+// file "LICENCE" distributed with Cforall.
+//
+// locks.hfa -- LIBCFATHREAD
+// Runtime locks that used with the runtime thread system.
+//
+// Author           : Colby Alexander Parsons
+// Created On       : Thu Jan 21 19:46:50 2021
+// Last Modified By :
+// Last Modified On :
+// Update Count     :
+//
+#define __cforall_thread__
 #include "locks.hfa"
 #include "kernel_private.hfa"
 …
 void ^?{}( blocking_lock & this ) {}
+void  ?{}( single_acquisition_lock & this ) {((blocking_lock &)this){ false, false };}
+void ^?{}( single_acquisition_lock & this ) {}
+void  ?{}( owner_lock & this ) {((blocking_lock &)this){ true, true };}
+void ^?{}( owner_lock & this ) {}
+void  ?{}( multiple_acquisition_lock & this ) {((blocking_lock &)this){ true, false };}
+void ^?{}( multiple_acquisition_lock & this ) {}
 void lock( blocking_lock & this ) with( this ) {
 …
         unlock( lock );
+}
-//-----------------------------------------------------------------------------
-// Overloaded routines for traits
-// These routines are temporary until an inheritance bug is fixed
-void   lock      ( single_acquisition_lock & this ) { lock   ( (blocking_lock &)this ); }
-void   unlock    ( single_acquisition_lock & this ) { unlock ( (blocking_lock &)this ); }
-void   on_wait   ( single_acquisition_lock & this ) { on_wait( (blocking_lock &)this ); }
-void   on_notify ( single_acquisition_lock & this, struct $thread * t ) { on_notify( (blocking_lock &)this, t ); }
-void   set_recursion_count( single_acquisition_lock & this, size_t recursion ) { set_recursion_count( (blocking_lock &)this, recursion ); }
-size_t get_recursion_count( single_acquisition_lock & this ) { return get_recursion_count( (blocking_lock &)this ); }
-void   lock     ( owner_lock & this ) { lock   ( (blocking_lock &)this ); }
-void   unlock   ( owner_lock & this ) { unlock ( (blocking_lock &)this ); }
-void   on_wait  ( owner_lock & this ) { on_wait( (blocking_lock &)this ); }
-void   on_notify( owner_lock & this, struct $thread * t ) { on_notify( (blocking_lock &)this, t ); }
-void   set_recursion_count( owner_lock & this, size_t recursion ) { set_recursion_count( (blocking_lock &)this, recursion ); }
-size_t get_recursion_count( owner_lock & this ) { return get_recursion_count( (blocking_lock &)this ); }
-void   lock     ( multiple_acquisition_lock & this ) { lock   ( (blocking_lock &)this ); }
-void   unlock   ( multiple_acquisition_lock & this ) { unlock ( (blocking_lock &)this ); }
-void   on_wait  ( multiple_acquisition_lock & this ) { on_wait( (blocking_lock &)this ); }
-void   on_notify( multiple_acquisition_lock & this, struct $thread * t ){ on_notify( (blocking_lock &)this, t ); }
-void   set_recursion_count( multiple_acquisition_lock & this, size_t recursion ){ set_recursion_count( (blocking_lock &)this, recursion ); }
-size_t get_recursion_count( multiple_acquisition_lock & this ){ return get_recursion_count( (blocking_lock &)this ); }
 //-----------------------------------------------------------------------------

libcfa/src/concurrency/locks.hfa

-                      rcd70477
+                      rf99f5ba
+//
+// Cforall Version 1.0.0 Copyright (C) 2021 University of Waterloo
+//
+// The contents of this file are covered under the licence agreement in the
+// file "LICENCE" distributed with Cforall.
+//
+// locks.hfa -- PUBLIC
+// Runtime locks that used with the runtime thread system.
+//
+// Author           : Colby Alexander Parsons
+// Created On       : Thu Jan 21 19:46:50 2021
+// Last Modified By :
+// Last Modified On :
+// Update Count     :
+//
 #pragma once
 #include <stdbool.h>
+#include "bits/locks.hfa"
+#include "bits/sequence.hfa"
+#include "invoke.h"
+#include "bits/weakso_locks.hfa"
 #include "time_t.hfa"
 #include "time.hfa"
+//----------
+struct single_acquisition_lock {
+        inline blocking_lock;
+};
+static inline void  ?{}( single_acquisition_lock & this ) {((blocking_lock &)this){ false, false };}
+static inline void ^?{}( single_acquisition_lock & this ) {}
+static inline void   lock      ( single_acquisition_lock & this ) { lock   ( (blocking_lock &)this ); }
+static inline void   unlock    ( single_acquisition_lock & this ) { unlock ( (blocking_lock &)this ); }
+static inline void   on_wait   ( single_acquisition_lock & this ) { on_wait( (blocking_lock &)this ); }
+static inline void   on_notify ( single_acquisition_lock & this, struct $thread * t ) { on_notify( (blocking_lock &)this, t ); }
+static inline void   set_recursion_count( single_acquisition_lock & this, size_t recursion ) { set_recursion_count( (blocking_lock &)this, recursion ); }
+static inline size_t get_recursion_count( single_acquisition_lock & this ) { return get_recursion_count( (blocking_lock &)this ); }
+//----------
+struct owner_lock {
+        inline blocking_lock;
+};
+static inline void  ?{}( owner_lock & this ) {((blocking_lock &)this){ true, true };}
+static inline void ^?{}( owner_lock & this ) {}
+static inline void   lock     ( owner_lock & this ) { lock   ( (blocking_lock &)this ); }
+static inline void   unlock   ( owner_lock & this ) { unlock ( (blocking_lock &)this ); }
+static inline void   on_wait  ( owner_lock & this ) { on_wait( (blocking_lock &)this ); }
+static inline void   on_notify( owner_lock & this, struct $thread * t ) { on_notify( (blocking_lock &)this, t ); }
+static inline void   set_recursion_count( owner_lock & this, size_t recursion ) { set_recursion_count( (blocking_lock &)this, recursion ); }
+static inline size_t get_recursion_count( owner_lock & this ) { return get_recursion_count( (blocking_lock &)this ); }
 //-----------------------------------------------------------------------------
 …
         info_thread(L) *& Next( info_thread(L) * this );
+}
-//-----------------------------------------------------------------------------
-// Blocking Locks
-struct blocking_lock {
-        // Spin lock used for mutual exclusion
-        __spinlock_t lock;
-        // List of blocked threads
-        Sequence( $thread ) blocked_threads;
-        // Count of current blocked threads
-        size_t wait_count;
-        // Flag if the lock allows multiple acquisition
-        bool multi_acquisition;
-        // Flag if lock can be released by non owner
-        bool strict_owner;
-        // Current thread owning the lock
-        struct $thread * owner;
-        // Number of recursion level
-        size_t recursion_count;
-};
-struct single_acquisition_lock {
-        inline blocking_lock;
-};
-struct owner_lock {
-        inline blocking_lock;
-};
-struct multiple_acquisition_lock {
-        inline blocking_lock;
-};
-void  ?{}( blocking_lock & this, bool multi_acquisition, bool strict_owner );
-void ^?{}( blocking_lock & this );
-void  ?{}( single_acquisition_lock & this );
-void ^?{}( single_acquisition_lock & this );
-void  ?{}( owner_lock & this );
-void ^?{}( owner_lock & this );
-void  ?{}( multiple_acquisition_lock & this );
-void ^?{}( multiple_acquisition_lock & this );
-void lock( blocking_lock & this );
-bool try_lock( blocking_lock & this );
-void unlock( blocking_lock & this );
-void on_notify( blocking_lock & this, struct $thread * t );
-void on_wait( blocking_lock & this );
-size_t wait_count( blocking_lock & this );
-void set_recursion_count( blocking_lock & this, size_t recursion );
-size_t get_recursion_count( blocking_lock & this );
-void lock( single_acquisition_lock & this );
-void unlock( single_acquisition_lock & this );
-void on_notify( single_acquisition_lock & this, struct $thread * t );
-void on_wait( single_acquisition_lock & this );
-void set_recursion_count( single_acquisition_lock & this, size_t recursion );
-size_t get_recursion_count( single_acquisition_lock & this );
-void lock( owner_lock & this );
-void unlock( owner_lock & this );
-void on_notify( owner_lock & this, struct $thread * t );
-void on_wait( owner_lock & this );
-void set_recursion_count( owner_lock & this, size_t recursion );
-size_t get_recursion_count( owner_lock & this );
-void lock( multiple_acquisition_lock & this );
-void unlock( multiple_acquisition_lock & this );
-void on_notify( multiple_acquisition_lock & this, struct $thread * t );
-void on_wait( multiple_acquisition_lock & this );
-void set_recursion_count( multiple_acquisition_lock & this, size_t recursion );
-size_t get_recursion_count( multiple_acquisition_lock & this );
 //-----------------------------------------------------------------------------

libcfa/src/stdlib.hfa

-                      rcd70477
+                      rf99f5ba
 // Created On       : Thu Jan 28 17:12:35 2016
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Mon Jan 18 21:51:13 2021
 // Update Count     : 569
+// Last Modified On : Thu Jan 21 22:02:13 2021
+// Update Count     : 574
 //
 …
                                 #pragma GCC diagnostic push
                                 #pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
+                                memcpy( (char *)ptr + i, &Fill.t, sizeof(Fill.t) );
+                                assert( size <= sizeof(Fill.t) );
+                                memcpy( (char *)ptr + i, &Fill.t, size );
                                 #pragma GCC diagnostic pop
+                        }

src/Parser/parser.yy

-                      rcd70477
+                      rf99f5ba
 // Created On       : Sat Sep  1 20:22:55 2001
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Mon Jan 11 21:32:10 2021
 // Update Count     : 4633
+// Last Modified On : Wed Jan 27 08:58:56 2021
+// Update Count     : 4680
 //
 …
 %{
 #define YYDEBUG_LEXER_TEXT (yylval)                                             // lexer loads this up each time
+#define YYDEBUG_LEXER_TEXT( yylval )                                    // lexer loads this up each time
 #define YYDEBUG 1                                                                               // get the pretty debugging code to compile
 #define YYERROR_VERBOSE                                                                 // more information in syntax errors
 …
 extern TypedefTable typedefTable;
 stack< LinkageSpec::Spec > linkageStack;
+stack<LinkageSpec::Spec> linkageStack;
 bool appendStr( string & to, string & from ) {
 …
         ConstantExpr * constant = dynamic_cast<ConstantExpr *>(type->expr.get());
         if ( constant && (constant->get_constant()->get_value() == "0" || constant->get_constant()->get_value() == "1") ) {
         type = new ExpressionNode( new CastExpr( maybeMoveBuild< Expression >(type), new BasicType( Type::Qualifiers(), BasicType::SignedInt ) ) );
+                type = new ExpressionNode( new CastExpr( maybeMoveBuild<Expression>(type), new BasicType( Type::Qualifiers(), BasicType::SignedInt ) ) );
         } // if
         return new ForCtrl(
 …
 %type<decl> type_qualifier type_qualifier_name forall type_qualifier_list_opt type_qualifier_list
 %type<decl> type_specifier type_specifier_nobody
+%type<decl> type_specifier type_specifier_nobody enum_specifier_nobody
 %type<decl> variable_declarator variable_ptr variable_array variable_function
 %type<decl> variable_abstract_declarator variable_abstract_ptr variable_abstract_array variable_abstract_function
 %type<decl> attribute_list_opt attribute_list attribute_name_list attribute attribute_name
+%type<decl> attribute_list_opt attribute_list attribute_opt attribute attribute_name_list attribute_name
 // initializers
 …
                 { $$ = $2; }
         | '(' compound_statement ')'                                            // GCC, lambda expression
                 { $$ = new ExpressionNode( new StmtExpr( dynamic_cast< CompoundStmt * >(maybeMoveBuild< Statement >($2) ) ) ); }
+                { $$ = new ExpressionNode( new StmtExpr( dynamic_cast<CompoundStmt *>(maybeMoveBuild<Statement>($2) ) ) ); }
         | type_name '.' identifier                                                      // CFA, nested type
                 { SemanticError( yylloc, "Qualified name is currently unimplemented." ); $$ = nullptr; }
 …
+                {
                         // create a GenericExpr wrapper with one association pair
                         $$ = new GenericExpr( nullptr, { { maybeMoveBuildType($1), maybeMoveBuild<Expression>($3) } } );
+                        $$ = new GenericExpr( nullptr, { { maybeMoveBuildType($1), maybeMoveBuild<Expression>( $3 ) } } );
+                }
         | DEFAULT ':' assignment_expression
                 { $$ = new GenericExpr( nullptr, { { maybeMoveBuild<Expression>($3) } } ); }
+                { $$ = new GenericExpr( nullptr, { { maybeMoveBuild<Expression>( $3 ) } } ); }
+        ;
 …
                         switch ( $1 ) {
                           case OperKinds::AddressOf:
                                 $$ = new ExpressionNode( new AddressExpr( maybeMoveBuild< Expression >( $2 ) ) );
+                                $$ = new ExpressionNode( new AddressExpr( maybeMoveBuild<Expression>( $2 ) ) );
                                 break;
                           case OperKinds::PointTo:
 …
                                 break;
                           case OperKinds::And:
                                 $$ = new ExpressionNode( new AddressExpr( new AddressExpr( maybeMoveBuild< Expression >( $2 ) ) ) );
+                                $$ = new ExpressionNode( new AddressExpr( new AddressExpr( maybeMoveBuild<Expression>( $2 ) ) ) );
                                 break;
                           default:
 …
                 { $$ = new ExpressionNode( build_unary_ptr( OperKinds::Decr, $2 ) ); }
         | SIZEOF unary_expression
                 { $$ = new ExpressionNode( new SizeofExpr( maybeMoveBuild< Expression >( $2 ) ) ); }
+                { $$ = new ExpressionNode( new SizeofExpr( maybeMoveBuild<Expression>( $2 ) ) ); }
         | SIZEOF '(' type_no_function ')'
                 { $$ = new ExpressionNode( new SizeofExpr( maybeMoveBuildType( $3 ) ) ); }
         | ALIGNOF unary_expression                                                      // GCC, variable alignment
                 { $$ = new ExpressionNode( new AlignofExpr( maybeMoveBuild< Expression >( $2 ) ) ); }
+                { $$ = new ExpressionNode( new AlignofExpr( maybeMoveBuild<Expression>( $2 ) ) ); }
         | ALIGNOF '(' type_no_function ')'                                      // GCC, type alignment
                 { $$ = new ExpressionNode( new AlignofExpr( maybeMoveBuildType( $3 ) ) ); }
 …
                 { $$ = new ExpressionNode( build_keyword_cast( $2, $5 ) ); }
         | '(' VIRTUAL ')' cast_expression                                       // CFA
                 { $$ = new ExpressionNode( new VirtualCastExpr( maybeMoveBuild< Expression >( $4 ), maybeMoveBuildType( nullptr ) ) ); }
+                { $$ = new ExpressionNode( new VirtualCastExpr( maybeMoveBuild<Expression>( $4 ), maybeMoveBuildType( nullptr ) ) ); }
         | '(' VIRTUAL type_no_function ')' cast_expression      // CFA
                 { $$ = new ExpressionNode( new VirtualCastExpr( maybeMoveBuild< Expression >( $5 ), maybeMoveBuildType( $3 ) ) ); }
+                { $$ = new ExpressionNode( new VirtualCastExpr( maybeMoveBuild<Expression>( $5 ), maybeMoveBuildType( $3 ) ) ); }
         | '(' RETURN type_no_function ')' cast_expression       // CFA
                 { SemanticError( yylloc, "Return cast is currently unimplemented." ); $$ = nullptr; }
 …
         assignment_expression
         | comma_expression ',' assignment_expression
                 { $$ = new ExpressionNode( new CommaExpr( maybeMoveBuild< Expression >( $1 ), maybeMoveBuild< Expression >( $3 ) ) ); }
+                { $$ = new ExpressionNode( new CommaExpr( maybeMoveBuild<Expression>( $1 ), maybeMoveBuild<Expression>( $3 ) ) ); }
+        ;
 …
         constant_expression                                                     { $$ = $1; }
         | constant_expression ELLIPSIS constant_expression      // GCC, subrange
                 { $$ = new ExpressionNode( new RangeExpr( maybeMoveBuild< Expression >( $1 ), maybeMoveBuild< Expression >( $3 ) ) ); }
+                { $$ = new ExpressionNode( new RangeExpr( maybeMoveBuild<Expression>( $1 ), maybeMoveBuild<Expression>( $3 ) ) ); }
         | subrange                                                                                      // CFA, subrange
+        ;
 …
                 { $$ = new StatementNode( build_computedgoto( $3 ) ); }
                 // A semantic check is required to ensure fallthru appears only in the body of a choose statement.
     | fall_through_name ';'                                                             // CFA
+        | fall_through_name ';'                                                         // CFA
                 { $$ = new StatementNode( build_branch( BranchStmt::FallThrough ) ); }
     | fall_through_name identifier_or_type_name ';'             // CFA
+        | fall_through_name identifier_or_type_name ';'         // CFA
                 { $$ = new StatementNode( build_branch( $2, BranchStmt::FallThrough ) ); }
         | fall_through_name DEFAULT ';'                                         // CFA
 …
 asm_operand:                                                                                    // GCC
         string_literal '(' constant_expression ')'
                 { $$ = new ExpressionNode( new AsmExpr( nullptr, $1, maybeMoveBuild< Expression >( $3 ) ) ); }
+                { $$ = new ExpressionNode( new AsmExpr( nullptr, $1, maybeMoveBuild<Expression>( $3 ) ) ); }
         | '[' IDENTIFIER ']' string_literal '(' constant_expression ')'
                 { $$ = new ExpressionNode( new AsmExpr( $2, $4, maybeMoveBuild< Expression >( $6 ) ) ); }
+                { $$ = new ExpressionNode( new AsmExpr( $2, $4, maybeMoveBuild<Expression>( $6 ) ) ); }
+        ;
 …
         | sue_type_specifier_nobody
         | type_type_specifier
+        ;
+enum_specifier_nobody:                                                                  // type specifier - {...}
+                // Preclude SUE declarations in restricted scopes (see type_specifier_nobody)
+        basic_type_specifier
+        | sue_type_specifier_nobody
+        ;
 …
+        ;
-fred:
-        // empty
-                { yyy = false; }
+        ;
 aggregate_type:                                                                                 // struct, union
         aggregate_key attribute_list_opt
 …
           '{' field_declaration_list_opt '}' type_parameters_opt
                 { $$ = DeclarationNode::newAggregate( $1, nullptr, $7, $5, true )->addQualifiers( $2 ); }
         | aggregate_key attribute_list_opt identifier fred
+        | aggregate_key attribute_list_opt identifier
+                {
                         typedefTable.makeTypedef( *$3, forall || typedefTable.getEnclForall() ? TYPEGENname : TYPEDEFname ); // create typedef
 …
+                }
           '{' field_declaration_list_opt '}' type_parameters_opt
                 { $$ = DeclarationNode::newAggregate( $1, $3, $9, $7, true )->addQualifiers( $2 ); }
         | aggregate_key attribute_list_opt type_name fred
+                { $$ = DeclarationNode::newAggregate( $1, $3, $8, $6, true )->addQualifiers( $2 ); }
+        | aggregate_key attribute_list_opt type_name
+                {
                         // for type_name can be a qualified type name S.T, in which case only the last name in the chain needs a typedef (other names in the chain should already have one)
 …
+                }
           '{' field_declaration_list_opt '}' type_parameters_opt
                 { $$ = DeclarationNode::newAggregate( $1, $3->type->symbolic.name, $9, $7, true )->addQualifiers( $2 ); }
+                { $$ = DeclarationNode::newAggregate( $1, $3->type->symbolic.name, $8, $6, true )->addQualifiers( $2 ); }
         | aggregate_type_nobody
+        ;
 …
 aggregate_type_nobody:                                                                  // struct, union - {...}
         aggregate_key attribute_list_opt identifier fred
+        aggregate_key attribute_list_opt identifier
+                {
                         typedefTable.makeTypedef( *$3, forall || typedefTable.getEnclForall() ? TYPEGENname : TYPEDEFname );
 …
                         $$ = DeclarationNode::newAggregate( $1, $3, nullptr, nullptr, false )->addQualifiers( $2 );
+                }
         | aggregate_key attribute_list_opt type_name fred
+        | aggregate_key attribute_list_opt type_name
+                {
                         forall = false;                                                         // reset
 …
+        ;
+// Cannot use attribute_list_opt because of ambiguity with enum_specifier_nobody, which already parses attribute.
+// Hence, only a single attribute is allowed after the "ENUM".
 enum_type:                                                                                              // enum
         ENUM attribute_list_opt '{' enumerator_list comma_opt '}'
+        ENUM attribute_opt '{' enumerator_list comma_opt '}'
                 { $$ = DeclarationNode::newEnum( nullptr, $4, true )->addQualifiers( $2 ); }
         | ENUM attribute_list_opt identifier
+        | ENUM attribute_opt identifier
                 { typedefTable.makeTypedef( *$3 ); }
           '{' enumerator_list comma_opt '}'
                 { $$ = DeclarationNode::newEnum( $3, $6, true )->addQualifiers( $2 ); }
         | ENUM attribute_list_opt type_name
+        | ENUM attribute_opt typedef                                            // enum cannot be generic
           '{' enumerator_list comma_opt '}'
+                { $$ = DeclarationNode::newEnum( $3->type->symbolic.name, $5, true )->addQualifiers( $2 ); }
+                { $$ = DeclarationNode::newEnum( $3->name, $5, true )->addQualifiers( $2 ); }
+        | ENUM enum_specifier_nobody '{' enumerator_list comma_opt '}'
+                // { $$ = DeclarationNode::newEnum( nullptr, $4, true ); }
+                { SemanticError( yylloc, "Typed enumeration is currently unimplemented." ); $$ = nullptr; }
+        | ENUM enum_specifier_nobody declarator '{' enumerator_list comma_opt '}'
+                // {
+                //      typedefTable.makeTypedef( *$3->name );
+                //      $$ = DeclarationNode::newEnum( nullptr, $5, true );
+                // }
+                { SemanticError( yylloc, "Typed enumeration is currently unimplemented." ); $$ = nullptr; }
         | enum_type_nobody
+        ;
 enum_type_nobody:                                                                               // enum - {...}
         ENUM attribute_list_opt identifier
+        ENUM attribute_opt identifier
+                {
                         typedefTable.makeTypedef( *$3 );
                         $$ = DeclarationNode::newEnum( $3, 0, false )->addQualifiers( $2 );
+                }
         | ENUM attribute_list_opt type_name
+        | ENUM attribute_opt type_name                                          // enum cannot be generic
+                {
                         typedefTable.makeTypedef( *$3->type->symbolic.name );
 …
         // empty
                 { $$ = nullptr; }
+        | '=' constant_expression
+                { $$ = $2; }
+        // | '=' constant_expression
+        //      { $$ = $2; }
+        | '=' initializer
+                { $$ = $2->get_expression(); }                                  // FIX ME: enum only deals with constant_expression
+        ;
 …
                 { $$ = $3; }
         | '[' push constant_expression ELLIPSIS constant_expression pop ']' // GCC, multiple array elements
                 { $$ = new ExpressionNode( new RangeExpr( maybeMoveBuild< Expression >( $3 ), maybeMoveBuild< Expression >( $5 ) ) ); }
+                { $$ = new ExpressionNode( new RangeExpr( maybeMoveBuild<Expression>( $3 ), maybeMoveBuild<Expression>( $5 ) ) ); }
         | '.' '[' push field_name_list pop ']'                          // CFA, tuple field selector
                 { $$ = $4; }
 …
 type_parameter:                                                                                 // CFA
         type_class identifier_or_type_name
+                {   typedefTable.addToScope( *$2, TYPEDEFname, "9" );
+                        if ( $1 == TypeDecl::Otype ) { SemanticError( yylloc, "otype keyword is deprecated" ); }
+                        if ( $1 == TypeDecl::Dtype ) { SemanticError( yylloc, "dtype keyword is deprecated" ); }
+                        if ( $1 == TypeDecl::Ttype ) { SemanticError( yylloc, "ttype keyword is deprecated" ); }
+                {
+                        typedefTable.addToScope( *$2, TYPEDEFname, "9" );
+                        if ( $1 == TypeDecl::Otype ) { SemanticError( yylloc, "otype keyword is deprecated, use T " ); }
+                        if ( $1 == TypeDecl::Dtype ) { SemanticError( yylloc, "dtype keyword is deprecated, use T &" ); }
+                        if ( $1 == TypeDecl::Ttype ) { SemanticError( yylloc, "ttype keyword is deprecated, use T ..." ); }
+                }
           type_initializer_opt assertion_list_opt
 …
 subrange:
         constant_expression '~' constant_expression                     // CFA, integer subrange
                 { $$ = new ExpressionNode( new RangeExpr( maybeMoveBuild< Expression >( $1 ), maybeMoveBuild< Expression >( $3 ) ) ); }
+                { $$ = new ExpressionNode( new RangeExpr( maybeMoveBuild<Expression>( $1 ), maybeMoveBuild<Expression>( $3 ) ) ); }
+        ;
 …
         | attribute_list attribute
                 { $$ = $2->addQualifiers( $1 ); }
+        ;
+attribute_opt:
+        // empty
+                { $$ = nullptr; }
+        | attribute
+        ;

tests/.expect/attributes.nast.x64.txt

-                      rcd70477
+                      rf99f5ba
+}
 struct __attribute__ ((unused)) __anonymous0 {
+struct __anonymous0 {
 };
 static inline void _X12_constructorFv_S12__anonymous0_autogen___1(struct __anonymous0 *_X4_dstS12__anonymous0_1);
 …
     return _X4_retS12__anonymous0_1;
+}
+__attribute__ ((unused)) struct __anonymous0 _X5DummyS12__anonymous0_1;
 struct __attribute__ ((unused)) Agn1;
 struct __attribute__ ((unused)) Agn2 {

tests/.expect/attributes.nast.x86.txt

-                      rcd70477
+                      rf99f5ba
+}
 struct __attribute__ ((unused)) __anonymous0 {
+struct __anonymous0 {
 };
 static inline void _X12_constructorFv_S12__anonymous0_autogen___1(struct __anonymous0 *_X4_dstS12__anonymous0_1);
 …
     return _X4_retS12__anonymous0_1;
+}
+__attribute__ ((unused)) struct __anonymous0 _X5DummyS12__anonymous0_1;
 struct __attribute__ ((unused)) Agn1;
 struct __attribute__ ((unused)) Agn2 {

tests/.expect/attributes.oast.x64.txt

-                      rcd70477
+                      rf99f5ba
+}
 struct __attribute__ ((unused)) __anonymous0 {
+struct __anonymous0 {
 };
 static inline void _X12_constructorFv_S12__anonymous0_autogen___1(struct __anonymous0 *_X4_dstS12__anonymous0_1);
 …
     return _X4_retS12__anonymous0_1;
+}
+__attribute__ ((unused)) struct __anonymous0 _X5DummyS12__anonymous0_1;
 struct __attribute__ ((unused)) Agn1;
 struct __attribute__ ((unused)) Agn2 {

tests/.expect/attributes.oast.x86.txt

-                      rcd70477
+                      rf99f5ba
+}
 struct __attribute__ ((unused)) __anonymous0 {
+struct __anonymous0 {
 };
 static inline void _X12_constructorFv_S12__anonymous0_autogen___1(struct __anonymous0 *_X4_dstS12__anonymous0_1);
 …
     return _X4_retS12__anonymous0_1;
+}
+__attribute__ ((unused)) struct __anonymous0 _X5DummyS12__anonymous0_1;
 struct __attribute__ ((unused)) Agn1;
 struct __attribute__ ((unused)) Agn2 {

tests/alloc2.cfa

rcd70477	rf99f5ba
16	16	bool passed = (malloc_size(ip) == size) && (malloc_usable_size(ip) >= size) && (malloc_alignment(ip) == align) && ((uintptr_t)ip % align == 0);
17	17	if (!passed) {
18		printf("failed test %3d: %4~~lu %4lu but got %4lu ( %3lu ) %4l~~u\n", tests_total, size, align, malloc_size(ip), malloc_usable_size(ip), malloc_alignment(ip));
	18	printf("failed test %3d: %4zu %4zu but got %4zu ( %3zu ) %4zu\n", tests_total, size, align, malloc_size(ip), malloc_usable_size(ip), malloc_alignment(ip));
19	19	tests_failed += 1;
20	20	}

tests/attributes.cfa

-                      rcd70477
+                      rf99f5ba
 // Created On       : Mon Feb  6 16:07:02 2017
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Tue Nov  6 17:51:12 2018
 // Update Count     : 17
+// Last Modified On : Mon Jan 25 21:26:41 2021
+// Update Count     : 20
 //
 …
 // aggregate_name
 struct __attribute__(( unused )) {};
+struct __attribute__(( unused )) {} Dummy;
 struct __attribute__(( unused )) Agn1;
 struct __attribute__(( unused )) Agn2 {};

tools/prettyprinter/Makefile.am

-                      rcd70477
+                      rf99f5ba
 ## Created On       : Wed Jun 28 12:07:10 2017
 ## Last Modified By : Peter A. Buhr
 ## Last Modified On : Mon Apr 16 09:43:23 2018
 ## Update Count     : 20
+## Last Modified On : Thu Jan 28 08:48:22 2021
+## Update Count     : 23
 ###############################################################################
 …
 BUILT_SOURCES = parser.hh
 AM_YFLAGS = -d -t -v
+AM_YFLAGS = -d -t -v -Wno-yacc
 SRC = lex.ll \
 …
 pretty_CXXFLAGS = -Wno-deprecated -Wall -DYY_NO_INPUT -O2 -g -std=c++14
 MAINTAINERCLEANFILES = parser.output
+MOSTLYCLEANFILES = parser.output

tools/prettyprinter/ParserTypes.h

-                      rcd70477
+                      rf99f5ba
 // Created On       : Sun Dec 16 15:00:49 2001
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Sat Jul 22 10:13:09 2017
 // Update Count     : 175
+// Last Modified On : Tue Jan 26 23:05:34 2021
+// Update Count     : 176
 //
 #pragma once
 int yylex();
+extern "C" int yylex();
 #include <string>

tools/prettyprinter/parser.yy

-                      rcd70477
+                      rf99f5ba
 // Created On       : Sat Dec 15 13:44:21 2001
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Sun Apr 15 21:40:30 2018
 // Update Count     : 1052
+// Last Modified On : Tue Jan 26 22:50:03 2021
+// Update Count     : 1053
 //
 …
 #define YYDEBUG_LEXER_TEXT( yylval )                                    // lexer loads this up each time
 #define YYDEBUG 1                                                                               // get the pretty debugging code to compile
+#define YYERROR_VERBOSE                                                                 // more information in syntax errors
 #include <iostream>

Context Navigation

Legend:

.gitignore

doc/LaTeXmacros/common.tex

doc/bibliography/pl.bib

doc/theses/andrew_beach_MMath/.gitignore

doc/theses/andrew_beach_MMath/existing.tex

doc/theses/andrew_beach_MMath/features.tex

doc/theses/andrew_beach_MMath/future.tex

doc/theses/andrew_beach_MMath/implement.tex

doc/theses/andrew_beach_MMath/unwinding.tex

doc/theses/andrew_beach_MMath/uw-ethesis.tex

libcfa/src/Makefile.am

libcfa/src/bits/collection.hfa

libcfa/src/bits/sequence.hfa

libcfa/src/concurrency/locks.cfa

libcfa/src/concurrency/locks.hfa

libcfa/src/stdlib.hfa

src/Parser/parser.yy

tests/.expect/attributes.nast.x64.txt

tests/.expect/attributes.nast.x86.txt

tests/.expect/attributes.oast.x64.txt

tests/.expect/attributes.oast.x86.txt

tests/alloc2.cfa

tests/attributes.cfa

tools/prettyprinter/Makefile.am

tools/prettyprinter/ParserTypes.h

tools/prettyprinter/parser.yy

Download in other formats: