Index: doc/generic_types/generic_types.tex
===================================================================
--- doc/generic_types/generic_types.tex	(revision 22444f4c2f676b5b2839258b1984eae410cf3faa)
+++ doc/generic_types/generic_types.tex	(revision 7a026ff9fb6fae7e12afeb2fe490474e97daed41)
@@ -149,12 +149,12 @@
 Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive.
 
-\CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that aims to add modern language features to C while maintaining both source compatibility with C and a familiar programming model for programmers. Four key design goals were set out in the original design of \CFA~\citep{Bilson03}:
+\CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that aims to add modern language features to C while maintaining both source compatibility with C and a familiar programming model for programmers. The four key design goals for \CFA~\citep{Bilson03} are:
 (1) The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler;
 (2) Standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler;
 (3) \CFA code must be at least as portable as standard C code;
 (4) Extensions introduced by \CFA must be translated in the most efficient way possible.
-These goals ensure existing C code-bases can be converted to \CFA incrementally and with minimal effort, and C programmers can productively generate \CFA code without training beyond the features they wish to employ. In its current implementation, \CFA is compiled by translating it to the GCC-dialect of C~\citep{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by GCC, meeting goals (1)-(3). Ultimately, a compiler is necessary for advanced features and optimal performance.
-
-\CFA has been previously extended with polymorphic functions and name overloading (including operator overloading) by \citet{Bilson03}, and deterministically-executed constructors and destructors by \citet{Schluntz17}. This paper builds on those contributions, identifying shortcomings in existing approaches to generic and variadic data types in C-like languages and presenting a design for generic and variadic types avoiding those shortcomings. Specifically, the solution is both reusable and type-checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions. The new constructs are empirically compared with both standard C and \CC; the results show the new design is comparable in performance.
+These goals ensure existing C code-bases can be converted to \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used. In its current implementation, \CFA is compiled by translating it to the GCC-dialect of C~\citep{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by GCC, meeting goals (1)-(3). Ultimately, a compiler is necessary for advanced features and optimal performance.
+
+This paper identifies shortcomings in existing approaches to generic and variadic data types in C-like languages and presents a design for generic and variadic types avoiding those shortcomings. Specifically, the solution is both reusable and type-checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions. The new constructs are empirically compared with both standard C and \CC; the results show the new design is comparable in performance.
 
 
@@ -224,5 +224,6 @@
 Call-site inferencing and nested functions provide a localized form of inheritance. For example, @qsort@ only sorts in ascending order using @<@. However, it is trivial to locally change this behaviour:
 \begin{lstlisting}
-{   int ?<?( double x, double y ) { return x `>` y; }	$\C{// override behaviour}$
+{
+	int ?<?( double x, double y ) { return x `>` y; }	$\C{// override behaviour}$
 	qsort( vals, size );					$\C{// descending sort}$
 }
@@ -257,5 +258,5 @@
 \begin{lstlisting}
 trait summable( otype T ) {
-	void ?{}(T*, zero_t);					$\C{// constructor from 0 literal}$
+	void ?{}( T *, zero_t );				$\C{// constructor from 0 literal}$
 	T ?+?( T, T );							$\C{// assortment of additions}$
 	T ?+=?( T *, T );
@@ -263,7 +264,6 @@
 	T ?++( T * );
 };
-forall( otype T | summable( T ) )
-  T sum( T a[$\,$], size_t size ) {
-	`T` total = { `0` };					$\C{// instantiate T from 0 but calling its constructor}$
+forall( otype T `| summable( T )` ) T sum( T a[$\,$], size_t size ) {  // use trait
+	`T` total = { `0` };					$\C{// instantiate T from 0 by calling its constructor}$
 	for ( unsigned int i = 0; i < size; i += 1 )
 		total `+=` a[i];					$\C{// select appropriate +}$