Index: doc/theses/aaron_moss_PhD/phd/Makefile
===================================================================
--- doc/theses/aaron_moss_PhD/phd/Makefile	(revision 031a88a9185c8893c2e6d735d2cd99e596118b4e)
+++ doc/theses/aaron_moss_PhD/phd/Makefile	(revision ec71a50975a9d7697d5de0e27072837d6203d86d)
@@ -1,8 +1,12 @@
-LATEX = pdflatex -interaction=nonstopmode
-BIBTEX = bibtex
+BUILD = build
+BIBDIR = ../../../bibliography
+TEXLIB = .:${BUILD}:${BIBDIR}:
+
+LATEX = TEXINPUTS=${TEXLIB} && export TEXINPUTS && pdflatex -interaction= -output-directory=${BUILD}
+BIBTEX = BIBINPUTS=${TEXLIB} && export BIBINPUTS && bibtex
 
 BASE = thesis
 DOCUMENT = ${BASE}.pdf
-AUX = ${BASE}.aux ${BASE}.bbl ${BASE}.blg ${BASE}.log ${BASE}.out ${BASE}.toc
+BIBFILE = ${BIBDIR}/pl.bib
 
 SOURCES = ${addsuffix .tex, \
@@ -23,16 +27,19 @@
 
 clean : 
-	@rm -frv ${DOCUMENT} ${AUX}
+	@rm -fv ${BUILD}/*
 
 wc :
 	wc ${SOURCES}
 
-${DOCUMENT} : ${SOURCES}
+${DOCUMENT} : ${SOURCES} ${BUILD}
 	${LATEX} ${BASE}
 	${LATEX} ${BASE}
 
-rebuild-refs : ${SOURCES} aaron-thesis.bib
+rebuild-refs : ${SOURCES} ${BIBFILE} ${BUILD}
 	${LATEX} ${BASE}
-	${BIBTEX} ${BASE}
+	${BIBTEX} ${BUILD}/${BASE}
 	${LATEX} ${BASE}
 	${LATEX} ${BASE}
+
+${BUILD}: 
+	mkdir -p ${BUILD}
Index: doc/theses/aaron_moss_PhD/phd/aaron-thesis.bib
===================================================================
--- doc/theses/aaron_moss_PhD/phd/aaron-thesis.bib	(revision 031a88a9185c8893c2e6d735d2cd99e596118b4e)
+++ 	(revision )
@@ -1,97 +1,0 @@
-%    Predefined journal names:
-%  acmcs: Computing Surveys		acta: Acta Infomatica
-@string{acta="Acta Infomatica"}
-%  cacm: Communications of the ACM
-%  ibmjrd: IBM J. Research & Development ibmsj: IBM Systems Journal
-%  ieeese: IEEE Trans. on Soft. Eng.	ieeetc: IEEE Trans. on Computers
-%  ieeetcad: IEEE Trans. on Computer-Aided Design of Integrated Circuits
-%  ipl: Information Processing Letters	jacm: Journal of the ACM
-%  jcss: J. Computer & System Sciences	scp: Science of Comp. Programming
-%  sicomp: SIAM J. on Computing		tocs: ACM Trans. on Comp. Systems
-%  tods: ACM Trans. on Database Sys.	tog: ACM Trans. on Graphics
-%  toms: ACM Trans. on Math. Software	toois: ACM Trans. on Office Info. Sys.
-%  toplas: ACM Trans. on Prog. Lang. & Sys.
-%  tcs: Theoretical Computer Science
-@string{ieeepds="IEEE Transactions on Parallel and Distributed Systems"}
-@string{ieeese="IEEE Transactions on Software Engineering"}
-@string{spe="Software---\-Practice and Experience"}
-@string{ccpe="Concurrency and Computation: Practice and Experience"}
-@string{sigplan="SIGPLAN Notices"}
-@string{joop="Journal of Object-Oriented Programming"}
-@string{popl="Conference Record of the ACM Symposium on Principles of Programming Languages"}
-@string{osr="Operating Systems Review"}
-@string{pldi="Programming Language Design and Implementation"}
-@string{toplas="Transactions on Programming Languages and Systems"}
-@string{mathann="Mathematische Annalen"}
-
-@mastersthesis{Bilson03,
-    keywords	= {Cforall, parametric polymorphism, overloading},
-    contributer	= {pabuhr@plg},
-    author	= {Richard C. Bilson},
-    title	= {Implementing Overloading and Polymorphism in \textsf{C}$\mathbf{\forall}$},
-    school	= {School of Computer Science, University of Waterloo},
-    year	= 2003,
-    address	= {Waterloo, Ontario, Canada, N2L 3G1},
-    note	= {\href{http://plg.uwaterloo.ca/theses/BilsonThesis.pdf}{http://\-plg.uwaterloo.ca/\-theses/\-BilsonThesis.pdf}},
-}
-
-@article{Buhr94a,
-    keywords	= {assignment, parameter passing, multiple assignment},
-    contributer	= {pabuhr@plg},
-    author	= {P. A. Buhr and David Till and C. R. Zarnke},
-    title	= {Assignment as the Sole Means of Updating Objects},
-    journal	= spe,
-    month	= sep,
-    year	= 1994,
-    volume	= 24,
-    number	= 9,
-    pages	= {835-870},
-}
-
-@mastersthesis{Delisle18,
-    author	= {Thierry Delisle },
-    title	= {Concurrency in \textsf{C}$\mathbf{\forall}$},
-    school	= {School of Computer Science, University of Waterloo},
-    year	= 2018,
-    address	= {Waterloo, Ontario, Canada, N2L 3G1},
-    note	= {\href{https://uwspace.uwaterloo.ca/handle/10012/12888}{https://\-uwspace.uwaterloo.ca/\-handle/\-10012/\-12888}},
-}
-
-@phdthesis{Ditchfield92,
-    keywords	= {C, parametric polymorphism, overloading},
-    contributer	= {pabuhr@plg},
-    author	= {Glen Jeffrey Ditchfield},
-    title	= {Contextual Polymorphism},
-    school	= {Department of Computer Science, University of Waterloo},
-    year	= 1992,
-    address	= {Waterloo, Ontario, Canada, N2L 3G1},
-    note	= {\href{http://plg.uwaterloo.ca/theses/DitchfieldThesis.pdf}{http://\-plg.uwaterloo.ca/\-theses/\-DitchfieldThesis.pdf}}
-}
-
-@article{Moss18,
-    keywords	= {concurrency, C++},
-    contributer	= {pabuhr@plg},
-    author	= {Aaron Moss and Robert Schluntz and Peter A. Buhr},
-    title	= {\textsf{C}$\mathbf{\forall}$ : Adding Modern Programming Language Features to C},
-    year	= 2018,
-    journal	= spe,
-    note	= {Accepted, to appear},
-}
-
-@mastersthesis{Schluntz17,
-    keywords 	= {constructors, destructors, tuples},
-    author	= {Robert Schluntz},
-    title	= {Resource Management and Tuples in \textsf{C}$\mathbf{\forall}$},
-    school	= {School of Computer Science, University of Waterloo},
-    year	= 2017,
-    address	= {Waterloo, Ontario, Canada, N2L 3G1},
-    note	= {\href{https://uwspace.uwaterloo.ca/handle/10012/11830}{https://\-uwspace.uwaterloo.ca/\-handle/\-10012/\-11830}},
-}
-
-@misc{TIOBE,
-    contributer	= {pabuhr@plg},
-    key		= {TIOBE Index},
-    title	= {{TIOBE} Index},
-    howpublished= {\href{http://www.tiobe.com/tiobe_index}{http://\-www.tiobe.com/\-tiobe\_index}},
-    optnote	= {Accessed: 2018-08},
-}
Index: doc/theses/aaron_moss_PhD/phd/background.tex
===================================================================
--- doc/theses/aaron_moss_PhD/phd/background.tex	(revision 031a88a9185c8893c2e6d735d2cd99e596118b4e)
+++ doc/theses/aaron_moss_PhD/phd/background.tex	(revision ec71a50975a9d7697d5de0e27072837d6203d86d)
@@ -1,3 +1,3 @@
-\chapter{Background}
+\chapter{\CFA{}}
 
 \CFA{} adds a number of features to C, some of them providing significant increases to the expressive power of the language, but all designed to maintain the existing procedural programming paradigm of C and to be as orthogonal as possible to each other. 
@@ -21,5 +21,5 @@
 It is important to note that \CFA{} is not an object-oriented language. 
 This is a deliberate choice intended to maintain the applicability of the mental model and language idioms already possessed by C programmers. 
-This choice is in marked contrast to \CC{}, which, though it has backward-compatibility with C on the source code level, is a much larger and more complex language, and requires extensive developer re-training before they can write idiomatic, efficient code in \CC{}'s object-oriented paradigm.
+This choice is in marked contrast to \CC{}, which, though it has backward-compatibility with C on the source code level, is a much larger and more complex language, and requires extensive developer re-training to write idiomatic, efficient code in \CC{}'s object-oriented paradigm.
 
 \CFA{} does have a system of implicit type conversions derived from C's ``usual arithmetic conversions''; while these conversions may be thought of as something like an inheritance hierarchy, the underlying semantics are significantly different and such an analogy is loose at best. 
@@ -62,9 +62,9 @@
 struct counter { int x; };
 
-counter& `++?`(counter& c) { ++c.x; return c; }  $\C{// pre-increment}$
-counter `?++`(counter& c) {  $\C{// post-increment}$
+counter& `++?`(counter& c) { ++c.x; return c; }  $\C[2in]{// pre-increment}$
+counter `?++`(counter& c) {  $\C[2in]{// post-increment}$
 	counter tmp = c; ++c; return tmp;
 }
-bool `?<?`(const counter& a, const counter& b) {  $\C{// comparison}$
+bool `?<?`(const counter& a, const counter& b) {  $\C[2in]{// comparison}$
 	return a.x < b.x;
 }
@@ -73,5 +73,21 @@
 Together, \CFA{}'s backward-compatibility with C and the inclusion of this operator overloading feature imply that \CFA{} must select among function overloads using a method compatible with C's ``usual arithmetic conversions''\cit{}, so as to present user programmers with only a single set of overloading rules.
 
-\subsection{Polymorphic Functions}
+\subsubsection{Special Literal Types}
+
+Literal !0! is also used polymorphically in C; it may be either integer zero or the null value of any pointer type. 
+\CFA{} provides a special type for the !0! literal, !zero_t!, so that users can define a zero value for their own types without being forced to create a conversion from an integer or pointer type (though \CFA{} also includes implicit conversions from !zero_t! to the integer and pointer types for backward compatibility). 
+
+According to the C standard\cit{}, !0! is the only false value; any value that compares equal to zero is false, while any value that does not is true. 
+By this rule, boolean contexts such as !if ( x )! can always be equivalently rewritten as \lstinline{if ( (x) != 0 )}. 
+\CFACC{} applies this rewriting in all boolean contexts, so any type !T! can be made ``truthy'' (that is, given a boolean interpretation) in \CFA{} by defining an operator overload \lstinline{int ?!=?(T, zero_t)}; unlike \CC{} prior to the addition of explicit casts in \CCeleven{}, this design does not add comparability or convertablity to arbitrary integer types. 
+
+\CFA{} also includes a special type for !1!, !one_t!; like !zero_t!, !one_t! has built-in implicit conversions to the various integral types so that !1! maintains its expected semantics in legacy code. 
+The addition of !one_t! allows generic algorithms to handle the unit value uniformly for types where it is meaningful; a simple example of this is that polymorphic functions\footnote{discussed in Section~\ref{poly-func-sec}} in the \CFA{} prelude define !++x! and !x++! in terms of !x += 1!, allowing users to idiomatically define all forms of increment for a type !T! by defining the single function !T& ?+=?(T&, one_t)!; analogous overloads for the decrement operators are also present, and programmers can override any of these functions for a particular type if desired.
+
+\CFA{} previously allowed !0! and !1! to be the names of polymorphic variables, with separate overloads for !int 0!, !int 1!, and !forall(dtype T) T* 0!. 
+As revealed in my own work on generic types (Chapter~\ref{generic-chap}), the parameteric polymorphic zero variable was not generalizable to other types; though all null pointers have the same in-memory representation, the same cannot be said of the zero values of arbitrary types. 
+As such, variables that could represent !0! and !1! were phased out in favour of functions that could generate those values for a given type as appropriate.
+
+\subsection{Polymorphic Functions} \label{poly-func-sec}
 
 The most significant feature \CFA{} adds is parametric-polymorphic functions. 
@@ -91,5 +107,5 @@
 One benefit of this design is that it allows polymorphic functions to be separately compiled. 
 The forward declaration !forall(otype T) T identity(T);! uniquely defines a single callable function, which may be implemented in a different file. 
-The fact that there is only one implementation of each polymorphic function also reduces compile times relative to the template-expansion approach taken by \CC{}, as well as reducing binary sizes and runtime pressure on instruction cache at by re-using a single version of each function.
+The fact that there is only one implementation of each polymorphic function also reduces compile times relative to the template-expansion approach taken by \CC{}, as well as reducing binary sizes and runtime pressure on instruction cache by re-using a single version of each function.
 
 \subsubsection{Type Assertions}
@@ -117,10 +133,10 @@
 
 This version of !twice! works for any type !S! that has an addition operator defined for it, and it could be used to satisfy the type assertion on !four_times!. 
-\CFACC{} accomplishes this by creating a wrapper function calling !twice // (2)! with !S! bound to !double!, then providing this wrapper function to !four_times!\footnote{\lstinline{twice // (2)} could also have had a type parameter named \lstinline{T}; \CFA{} specifies renaming of the type parameters, which would avoid the name conflict with the type variable \lstinline{T} of \lstinline{four_times}}.
-
-Finding appropriate functions to satisfy type assertions is essentially a recursive case of expression resolution, as it takes a name (that of the type assertion) and attempts to match it to a suitable declaration \emph{in the current scope}. 
-If a polymorphic function can be used to satisfy one of its own type assertions, this recursion may not terminate, as it is possible that that function is examined as a candidate for its own type assertion unboundedly repeatedly. 
+\CFACC{} accomplishes this by creating a wrapper function calling !twice//(2)! with !S! bound to !double!, then providing this wrapper function to !four_times!\footnote{\lstinline{twice // (2)} could also have had a type parameter named \lstinline{T}; \CFA{} specifies renaming of the type parameters, which would avoid the name conflict with the type variable \lstinline{T} of \lstinline{four_times}}.
+
+Finding appropriate functions to satisfy type assertions is essentially a recursive case of expression resolution, as it takes a name (that of the type assertion) and attempts to match it to a suitable declaration in the current scope. 
+If a polymorphic function can be used to satisfy one of its own type assertions, this recursion may not terminate, as it is possible that that function is examined as a candidate for its own assertion unboundedly repeatedly. 
 To avoid such infinite loops, \CFACC{} imposes a fixed limit on the possible depth of recursion, similar to that employed by most \CC{} compilers for template expansion; this restriction means that there are some semantically well-typed expressions that cannot be resolved by \CFACC{}.
-\TODO{Update this with final state} One contribution made in the course of this thesis was modifying \CFACC{} to use the more flexible expression resolution algorithm for assertion matching, rather than the previous simpler approach of unification on the types of the functions.
+\TODO{Update this with final state} One contribution made in the course of this thesis was modifying \CFACC{} to use the more flexible expression resolution algorithm for assertion matching, rather than the simpler but limited previous approach of unification on the types of the functions.
 
 \subsubsection{Deleted Declarations}
@@ -175,10 +191,10 @@
 \begin{cfa}
 trait pointer_like(`otype Ptr, otype El`) {
-	El& *?(Ptr);  $\C{Ptr can be dereferenced to El}$
+	El& *?(Ptr);  $\C{// Ptr can be dereferenced to El}$
 };
 
 struct list {
 	int value;
-	list* next; $\C{may omit struct on type names}$
+	list* next; $\C{// may omit struct on type names}$
 };
 
@@ -200,6 +216,6 @@
 
 In addition to the multiple interpretations of an expression produced by name overloading and polymorphic functions, for backward compatibility \CFA{} must support all of the implicit conversions present in C, producing further candidate interpretations for expressions. 
-As mentioned above, C does not have an inheritance hierarchy of types, but the C standard's rules for the ``usual arithmetic conversions''\cit{} define which of the built-in tyhpes are implicitly convertable to which other types, and the relative cost of any pair of such conversions from a single source type. 
-\CFA{} adds to the usual arithmetic conversions rules defining the cost of binding a polymorphic type variable in a function call; such bindings are cheaper than any \emph{unsafe} (narrowing) conversion, \eg{} !int! to !char!, but more expensive than any \emph{safe} (widening) conversion, \eg{} !int! to !double!. 
+As mentioned above, C does not have an inheritance hierarchy of types, but the C standard's rules for the ``usual arithmetic conversions'\cit{} define which of the built-in types are implicitly convertible to which other types, and the relative cost of any pair of such conversions from a single source type. 
+\CFA{} adds rules to the usual arithmetic conversions defining the cost of binding a polymorphic type variable in a function call; such bindings are cheaper than any \emph{unsafe} (narrowing) conversion, \eg{} !int! to !char!, but more expensive than any \emph{safe} (widening) conversion, \eg{} !int! to !double!. 
 One contribution of this thesis, discussed in Section \TODO{add to resolution chapter}, is a number of refinements to this cost model to more efficiently resolve polymorphic function calls. 
 
@@ -208,14 +224,132 @@
 Note that which subexpression interpretation is minimal-cost may require contextual information to disambiguate. 
 For instance, in the example in Section~\ref{overloading-sec}, !max(max, -max)! cannot be unambiguously resolved, but !int m = max(max, -max)! has a single minimal-cost resolution. 
-While the interpretation !int m = (int)max((double)max, -(double)max)! is also a valid interpretation, it is not minimal-cost due to the unsafe cast from the !double! result of !max! to the !int!\footnote{The two \lstinline{double} casts function as type ascriptions selecting \lstinline{double max} rather than casts from \lstinline{int max} to \lstinline{double}, and as such are zero-cost.}. 
-These contextual effects make the expression resolution problem for \CFA{} both theoretically and practically difficult, but the observation driving the work in Chapter~\ref{resolution-chap} is that of the many top-level expressions in a given program, most will likely be straightforward and idiomatic so that programmers writing and maintaining the code can easily understand them; it follows that effective heuristics for common cases can bring down compiler runtime enough that a small proportion of harder-to-resolve expressions should not increase compiler runtime or memory usage inordinately.
+While the interpretation !int m = (int)max((double)max, -(double)max)! is also a valid interpretation, it is not minimal-cost due to the unsafe cast from the !double! result of !max! to !int!\footnote{The two \lstinline{double} casts function as type ascriptions selecting \lstinline{double max} rather than casts from \lstinline{int max} to \lstinline{double}, and as such are zero-cost.}. 
+These contextual effects make the expression resolution problem for \CFA{} both theoretically and practically difficult, but the observation driving the work in Chapter~\ref{resolution-chap} is that of the many top-level expressions in a given program, most are straightforward and idiomatic so that programmers writing and maintaining the code can easily understand them; it follows that effective heuristics for common cases can bring down compiler runtime enough that a small proportion of harder-to-resolve expressions does not inordinately increase overall compiler runtime or memory usage.
 
 \subsection{Type Features} \label{type-features-sec}
 
+The name overloading and polymorphism features of \CFA{} have the greatest effect on language design and compiler runtime, but there are a number of other features in the type system which have a smaller effect but are useful for code examples. 
+These features are described here. 
+
 \subsubsection{Reference Types}
 
-% TODO mention contribution on reference rebind
-
-\subsubsection{Lifetime Management}
-
-\subsubsection{0 and 1 Literals}
+One of the key ergonomic improvements in \CFA{} is reference types, designed and implemented by Robert Schluntz\cite{Schluntz17}. 
+Given some type !T!, a !T&! (``reference to !T!'') is essentially an automatically dereferenced pointer. 
+These types allow seamless pass-by-reference for function parameters, without the extraneous dereferencing syntax present in C; they also allow easy easy aliasing of nested values with a similarly convenient syntax. 
+A particular improvement is removing syntactic special cases for operators which take or return mutable values; for example, the use !a += b! of a compound assignment operator now matches its signature, !int& ?+=?(int&, int)!, as opposed to the previous syntactic special cases to automatically take the address of the first argument to !+=! and to mark its return value as mutable.
+
+The C standard makes heavy use of the concept of \emph{lvalue}, an expression with a memory address; its complement, \emph{rvalue} (a non-addressable expression) is not explicitly named. 
+In \CFA{}, the distinction between lvalue and rvalue can be reframed in terms of reference and non-reference types, with the benefit of being able to express the difference in user code. 
+\CFA{} references preserve the existing qualifier-dropping implicit lvalue-to-rvalue conversion from C (\eg{} a !const volatile int&! can be implicitly copied to a bare !int!)
+To make reference types more easily usable in legacy pass-by-value code, \CFA{} also adds an implicit rvalue-to-lvalue conversion, implemented by storing the value in a fresh compiler-generated temporary variable and passing a reference to that temporary. 
+To mitigate the ``!const! hell'' problem present in \CC{}, there is also a qualifier-dropping lvalue-to-lvalue conversion, also implemented by copying into a temporary:
+
+\begin{cfa}
+const int magic = 42;
+
+void inc_print( int& x ) { printf("%d\n", ++x); }
+
+print_inc( magic ); $\C{// legal; implicitly generated code in red below:}$
+
+`int tmp = magic;` $\C{// to safely strip const-qualifier}$
+`print_inc( tmp );` $\C{// tmp is incremented, magic is unchanged}$
+\end{cfa}
+
+Despite the similar syntax, \CFA{} references are significantly more flexible than \CC{} references. 
+The primary issue with \CC{} references is that it is impossible to extract the address of the reference variable rather than the address of the referred-to variable. 
+This breaks a number of the usual compositional properties of the \CC{} type system, \eg{} a reference cannot be re-bound to another variable, nor is it possible to take a pointer to, array of, or reference to a reference. 
+\CFA{} supports all of these use cases \TODO{test array} without further added syntax. 
+The key to this syntax-free feature support is an observation made by the author that the address of a reference is a lvalue. 
+In C, the address-of operator !&x! can only be applied to lvalue expressions, and always produces an immutable rvalue; \CFA{} supports reference re-binding by assignment to the address of a reference, and pointers to references by repeating the address-of operator:
+
+\begin{cfa}
+int x = 2, y = 3;
+int& r = x;  $\C{// r aliases x}$
+&r = &y; $\C{// r now aliases y}$
+int** p = &&r; $\C{// p points to r}$
+\end{cfa}
+
+For better compatibility with C, the \CFA{} team has chosen not to differentiate function overloads based on top-level reference types, and as such their contribution to the difficulty of \CFA{} expression resolution is largely restricted to the implementation details of normalization conversions and adapters. 
+
+\subsubsection{Resource Management}
+
+\CFA{} also supports the RAII (``Resource Acquisition is Initialization'') idiom originated by \CC{}, thanks to the object lifetime work of Robert Schluntz\cite{Schluntz17}. 
+This idiom allows a safer and more principled approach to resource management by tying acquisition of a resource to object initialization, with the corresponding resource release executed automatically at object finalization. 
+A wide variety of conceptual resources may be conveniently managed by this scheme, including heap memory, file handles, and software locks. 
+
+\CFA{}'s implementation of RAII is based on special constructor and destructor operators, available via the !x{ ... }! constructor syntax and !^x{ ... }! destructor syntax. 
+Each type has an overridable compiler-generated zero-argument constructor, copy constructor, assignment operator, and destructor, as well as a field-wise constructor for each appropriate prefix of the member fields of !struct! types. 
+For !struct! types the default versions of these operators call their equivalents on each field of the !struct!. 
+The main implication of these object lifetime functions for expression resolution is that they are all included as implicit type assertions for !otype! type variables, with a secondary effect being an increase in code size due to the compiler-generated operators. 
+Due to these implicit type assertions, assertion resolution is pervasive in \CFA{} polymorphic functions, even those without explicit type assertions. 
+Implicitly-generated code is shown in red in the following example:
+
+\begin{cfa}
+struct kv {
+	int key;
+	char* value;
+};
+
+`void ?{} (kv& this) {` $\C[3in]{// default constructor}$
+`	this.key{};` $\C[3in]{// call recursively on members}$
+`	this.value{};
+}
+
+void ?{} (kv& this, int key) {` $\C[3in]{// partial field constructor}$
+`	this.key{ key };
+	this.value{};` $\C[3in]{// default-construct missing fields}$
+`}
+
+void ?{} (kv& this, int key, char* value) {` $\C[3in]{// complete field constructor}$
+`	this.key{ key };
+	this.value{ value };
+}
+
+void ?{} (kv& this, kv that) {` $\C[3in]{// copy constructor}$
+`	this.key{ that.key };
+	this.value{ that.value };
+}
+
+kv ?=? (kv& this, kv that) {` $\C[3in]{// assignment operator}$
+`	this.key = that.key;
+	this.value = that.value;
+}
+
+void ^?{} (kv& this) {` $\C[3in]{// destructor}$
+`	^this.key{};
+	^this.value{};
+}`
+
+forall(otype T `| { void ?{}(T&); void ?{}(T&, T); T ?=?(T&, T); void ^?{}(T&); }`)
+void foo(T);
+\end{cfa}
+
+\subsubsection{Tuple Types}
+
+\CFA{} adds \emph{tuple types} to C, a syntactic facility for referring to lists of values anonymously or with a single identifier. 
+An identifier may name a tuple, a function may return one, and a tuple may be implicitly \emph{destructured} into its component values. 
+The implementation of tuples in \CFACC{}'s code generation is based on the generic types introduced in Chapter~\ref{generic-chap}, with one compiler-generated generic type for each tuple arity. 
+This allows tuples to take advantage of the same runtime optimizations available to generic types, while reducing code bloat. 
+An extended presentation of the tuple features of \CFA{} can be found in \cite{Moss18}, but the following example shows the basics:
+
+\begin{cfa}
+[char, char] x = ['!', '?']; $\C{// (1); tuple type and expression syntax}$
+int x = 2; $\C{// (2)}$
+
+forall(otype T)
+[T, T] swap( T a, T b ) { $\C{// (3)}$
+	return [b, a]; $\C{// one-line swap syntax}$
+}
+
+x = swap( x ); $\C{// destructure [char, char] x into two elements}$
+$\C{// cannot use int x, not enough arguments}$
+
+void swap( int, char, char ); $\C{// (4)}$
+
+swap( x, x ); $\C{// (4) on (2), (1)}$
+$\C{// not (3) on (2), (2) due to polymorphism cost}$
+\end{cfa}
+
+Tuple destructuring breaks the one-to-one relationship between identifiers and values. 
+This precludes some argument-parameter matching strategies for expression resolution, as well as cheap interpretation filters based on comparing number of parameters and arguments. 
+As an example, in the call to !swap( x, x )! above, the second !x! can be resolved starting at the second or third parameter of !swap!, depending which interpretation of !x! was chosen for the first argument.
Index: doc/theses/aaron_moss_PhD/phd/cfa-macros.tex
===================================================================
--- doc/theses/aaron_moss_PhD/phd/cfa-macros.tex	(revision 031a88a9185c8893c2e6d735d2cd99e596118b4e)
+++ doc/theses/aaron_moss_PhD/phd/cfa-macros.tex	(revision ec71a50975a9d7697d5de0e27072837d6203d86d)
@@ -20,5 +20,5 @@
 \newcommand{\LstCommentStyle}[1]{{\lst@basicstyle{\lst@commentstyle{#1}}}}
 
-\newcommand{\C}[2][2in]{\hfill\makebox[#1][l]{\LstCommentStyle{#2}}}
+\newcommand{\C}[2][3.5in]{\hfill\makebox[#1][l]{\LstCommentStyle{#2}}}
 
 % CFA programming language, based on ANSI C (with some gcc additions)
Index: doc/theses/aaron_moss_PhD/phd/generic-types.tex
===================================================================
--- doc/theses/aaron_moss_PhD/phd/generic-types.tex	(revision 031a88a9185c8893c2e6d735d2cd99e596118b4e)
+++ doc/theses/aaron_moss_PhD/phd/generic-types.tex	(revision ec71a50975a9d7697d5de0e27072837d6203d86d)
@@ -4,5 +4,10 @@
 Talk about generic types. Pull from Moss~\etal\cite{Moss18}.
 
+% TODO discuss layout function algorithm, application to separate compilation
+% TODO put a static const field in for _n_fields for each generic, describe utility for separate compilation
+
 % TODO mention impetus for zero_t design
 
 % TODO mention use in tuple-type implementation
+
+% TODO pull benchmarks from Moss et al.
Index: doc/theses/aaron_moss_PhD/phd/thesis.tex
===================================================================
--- doc/theses/aaron_moss_PhD/phd/thesis.tex	(revision 031a88a9185c8893c2e6d735d2cd99e596118b4e)
+++ doc/theses/aaron_moss_PhD/phd/thesis.tex	(revision ec71a50975a9d7697d5de0e27072837d6203d86d)
@@ -141,5 +141,5 @@
 \addcontentsline{toc}{chapter}{\textbf{References}}
 
-\bibliography{aaron-thesis}
+\bibliography{pl}
 % Tip 5: You can create multiple .bib files to organize your references. 
 % Just list them all in the \bibliogaphy command, separated by commas (no spaces).