Index: doc/papers/general/Paper.tex
===================================================================
--- doc/papers/general/Paper.tex	(revision b060aba307d27b81761d11a4448ee888c1919bc4)
+++ doc/papers/general/Paper.tex	(revision 6c7c63cec71bc05334536c6b43fd8ddca9d0a39c)
@@ -142,5 +142,5 @@
 % replace/adjust listing characters that look bad in sanserif
 literate={-}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.1ex}}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1
-	{~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
+	{~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 {@}{\small{@}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
 	{<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {->}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.075ex}}}\kern-0.2ex\textgreater}2,
 moredelim=**[is][\color{red}]{`}{`},
@@ -1290,5 +1290,5 @@
 The object is the implicit qualifier for the open structure-fields.
 
-All expressions in the expression list are open in ``parallel'' within the compound statement.
+All expressions in the expression list are open in parallel within the compound statement.
 This semantic is different from Pascal, which nests the openings from left to right.
 The difference between parallel and nesting occurs for fields with the same name and type:
@@ -1336,17 +1336,17 @@
 with ( (S)w ) { ... }						$\C{// unambiguous, cast}$
 \end{cfa}
-and @with@ expressions may be pointers and references (see Section~\ref{s:References}) to aggregates:
+and @with@ expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
 \begin{cfa}
 struct S { int i, j; } sv;
-with ( sv ) {								$\C{variable}$
+with ( sv ) {								$\C{implicit reference}$
 	S & sr = sv;
-	with ( sr ) {							$\C{reference}$
+	with ( sr ) {							$\C{explicit reference}$
 		S * sp = &sv;
-		with ( *sp ) {						$\C{pointer}$
+		with ( *sp ) {						$\C{computed reference}$
 			i = 3; j = 4;					$\C{\color{red}// sp-{\textgreater}i, sp-{\textgreater}j}$
 		}
-		i = 3; j = 4;						$\C{\color{red}// sr.i, sr.j}$
+		i = 2; j = 3;						$\C{\color{red}// sr.i, sr.j}$
 	}
-	i = 3; j = 4;							$\C{\color{red}// sv.i, sv.j}$
+	i = 1; j = 2;							$\C{\color{red}// sv.i, sv.j}$
 }
 \end{cfa}
@@ -1364,6 +1364,7 @@
 _Exception E { int fix; };
 void f() {
-	... _Resume E;
-	// control returns here after handler
+	E e;
+	... _Resume e;
+	... e.fix // control returns here after handler
 try {
 	f();
@@ -1376,5 +1377,6 @@
 _Exception E {};
 void f() {
-	... _Throw E;
+
+	... _Throw E{};
 	// control does NOT return here after handler
 try {
@@ -1391,9 +1393,10 @@
 \section{Declarations}
 
-It is important that \CFA subjectively ``feel like'' C to programmers.
-An important part of this subjective feel is maintaining C's procedural paradigm, as opposed to the object-oriented paradigm of other systems languages such as \CC and Rust.
-Maintaining this procedural paradigm means that C coding-patterns remain not only functional but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development.
-Nonetheless, some features of object-oriented languages are undeniably convenient but are independent of object-oriented programming;
-\CFA adapts these features to a procedural paradigm.
+Declarations in C have weaknesses and omissions.
+\CFA attempts to correct and add to C declarations, while ensuring \CFA subjectively ``feels like'' C.
+An important part of this subjective feel is maintaining C's syntax and procedural paradigm, as opposed to functional and object-oriented approaches in other systems languages such as \CC and Rust.
+Maintaining the C approach means that C coding-patterns remain not only useable but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development.
+Nevertheless, some features from other approaches are undeniably convenient;
+\CFA attempts to adapt these features to the C paradigm.
 
 
@@ -1538,5 +1541,5 @@
 \lstMakeShortInline@%
 \end{cquote}
-All specifiers must appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
+Specifiers must appear at the start of a \CFA routine declaration\footnote{\label{StorageClassSpecifier}.
 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}}.
 
@@ -1664,5 +1667,5 @@
 \end{lrbox}
 Rebinding allows \CFA references to be default-initialized (\eg to a null pointer\footnote{
-While effort has been put into non-null reference checking in \CC, the exercise seems moot for any non-managed languages, given that it only handles one of many different error situations:
+While effort has been put into non-null reference checking in \CC and Java, the exercise seems moot for any non-managed languages (C/\CC), given that it only handles one of many different error situations:
 \begin{cquote}
 \usebox{\LstBox}
@@ -1718,4 +1721,81 @@
 
 
+\subsection{Type Nesting}
+
+Nested types provide a mechanism to organize associated types and refactor a subset of fields into a named aggregate (\eg sub-aggregates @name@, @address@, @department@, within aggregate @employe@).
+Java nested types are dynamic (apply to objects), \CC are static (apply to the \lstinline[language=C++]@class@), and C hoists (refactors) nested types into the enclosing scope, meaning there is no need for type qualification.
+Since \CFA in not object-oriented, adopting dynamic scoping does not make sense;
+instead \CFA adopts \CC static nesting, using the field-selection operator ``@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``@::@'' (see Figure~\ref{f:TypeNestingQualification}).
+\begin{figure}
+\centering
+\lstDeleteShortInline@%
+\begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}	& \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}	& \multicolumn{1}{|c}{\textbf{\CFA}}	\\
+\hline
+\begin{cfa}
+struct S {
+	enum C { R, G, B };
+	struct T {
+		union U { int i, j; };
+		enum C c;
+		short int i, j;
+	};
+	struct T t;
+} s;
+
+int rtn() {
+	s.t.c = R;
+	struct T t = { R, 1, 2 };
+	enum C c;
+	union U u;
+}
+\end{cfa}
+&
+\begin{cfa}
+enum C { R, G, B };
+union U { int i, j; };
+struct T {
+	enum C c;
+	short int i, j;
+};
+struct S {
+	struct T t;
+} s;
+	
+
+
+
+
+
+
+\end{cfa}
+&
+\begin{cfa}
+struct S {
+	enum C { R, G, B };
+	struct T {
+		union U { int i, j; };
+		enum C c;
+		short int i, j;
+	};
+	struct T t;
+} s;
+
+int rtn() {
+	s.t.c = `S.`R;	// type qualification
+	struct `S.`T t = { `S.`R, 1, 2 };
+	enum `S.`C c;
+	union `S.T.`U u;
+}
+\end{cfa}
+\end{tabular}
+\lstMakeShortInline@%
+\caption{Type Nesting / Qualification}
+\label{f:TypeNestingQualification}
+\end{figure}
+In the left example in C, types @C@, @U@ and @T@ are implicitly hoisted outside of type @S@ into the containing block scope.
+In the right example in \CFA, the types are not hoisted and accessed .
+
+
 \subsection{Constructors and Destructors}
 
@@ -1807,78 +1887,4 @@
 Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg \lstinline|VLA a @= { 0, 0x0 }|, with the usual C initialization semantics. 
 The point of \lstinline|@=| is to provide a migration path from legacy C code to \CFA, by providing a mechanism to incrementally convert to implicit initialization.
-
-
-\subsection{Type Nesting}
-
-\CFA allows \newterm{type nesting}, and type qualification of the nested types (see Figure~\ref{f:TypeNestingQualification}), where as C hoists (refactors) nested types into the enclosing scope and has no type qualification.
-\begin{figure}
-\centering
-\lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
-\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}	& \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}	& \multicolumn{1}{|c}{\textbf{\CFA}}	\\
-\hline
-\begin{cfa}
-struct S {
-	enum C { R, G, B };
-	struct T {
-		union U { int i, j; };
-		enum C c;
-		short int i, j;
-	};
-	struct T t;
-} s;
-
-int rtn() {
-	s.t.c = R;
-	struct T t = { R, 1, 2 };
-	enum C c;
-	union U u;
-}
-\end{cfa}
-&
-\begin{cfa}
-enum C { R, G, B };
-union U { int i, j; };
-struct T {
-	enum C c;
-	short int i, j;
-};
-struct S {
-	struct T t;
-} s;
-	
-
-
-
-
-
-
-\end{cfa}
-&
-\begin{cfa}
-struct S {
-	enum C { R, G, B };
-	struct T {
-		union U { int i, j; };
-		enum C c;
-		short int i, j;
-	};
-	struct T t;
-} s;
-
-int rtn() {
-	s.t.c = `S.`R;	// type qualification
-	struct `S.`T t = { `S.`R, 1, 2 };
-	enum `S.`C c;
-	union `S.T.`U u;
-}
-\end{cfa}
-\end{tabular}
-\lstMakeShortInline@%
-\caption{Type Nesting / Qualification}
-\label{f:TypeNestingQualification}
-\end{figure}
-In the left example in C, types @C@, @U@ and @T@ are implicitly hoisted outside of type @S@ into the containing block scope.
-In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``@::@''.