Index: doc/papers/general/Paper.tex
===================================================================
--- doc/papers/general/Paper.tex	(revision 7ad6b6db8814dd8a1b75e812dfcb238f7ca69251)
+++ doc/papers/general/Paper.tex	(revision 43bbdf35433867f116ecf5b801b35ec007e3e2aa)
@@ -61,4 +61,12 @@
 \newcommand{\C}[2][\@empty]{\ifx#1\@empty\else\global\setlength{\columnposn}{#1}\global\columnposn=\columnposn\fi\hfill\makebox[\textwidth-\columnposn][l]{\lst@basicstyle{\LstCommentStyle{#2}}}}
 \newcommand{\CRT}{\global\columnposn=\gcolumnposn}
+
+% Denote newterms in particular font and index them without particular font and in lowercase, e.g., \newterm{abc}.
+% The option parameter provides an index term different from the new term, e.g., \newterm[\texttt{abc}]{abc}
+% The star version does not lowercase the index information, e.g., \newterm*{IBM}.
+\newcommand{\newtermFontInline}{\emph}
+\newcommand{\newterm}{\@ifstar\@snewterm\@newterm}
+\newcommand{\@newterm}[2][\@empty]{\lowercase{\def\temp{#2}}{\newtermFontInline{#2}}\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
+\newcommand{\@snewterm}[2][\@empty]{{\newtermFontInline{#2}}\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
 
 % Latin abbreviation
@@ -1040,48 +1048,70 @@
 \TODO{choose and fallthrough here as well?}
 
+
 \subsection{\texorpdfstring{\LstKeywordStyle{with} Clause / Statement}{with Clause / Statement}}
 \label{s:WithClauseStatement}
 
-In any programming language, some functions have a naturally close relationship with a particular data type. 
-Object-oriented programming allows this close relationship to be codified in the language by making such functions \emph{class methods} of their related data type.
-Class methods have certain privileges with respect to their associated data type, notably un-prefixed access to the fields of that data type. 
-When writing C functions in an object-oriented style, this un-prefixed access is swiftly missed, as access to fields of a @Foo* f@ requires an extra three characters @f->@ every time, which disrupts coding flow and clutters the produced code. 
-
-\TODO{Fill out section. Be sure to mention arbitrary expressions in with-blocks, recent change driven by Thierry to prioritize field name over parameters.}
-
-
-In object-oriented programming, there is an implicit first parameter, often names @self@ or @this@, which is elided.
+Grouping heterogenous data into \newterm{aggregate}s is a common programming practice, and an aggregate can be further organized into more complex structures, such as arrays and containers:
+\begin{cfa}
+struct S {								$\C{// aggregate}$
+	char c;								$\C{// fields}$
+	int i;
+	double d;
+};
+S s, as[10];
+\end{cfa}
+However, routines manipulating aggregates have repeition of the aggregate name to access its containing fields:
+\begin{cfa}
+void f( S s ) {
+	`s.`c; `s.`i; `s.`d;				$\C{// access containing fields}$
+}
+\end{cfa}
+A similar situation occurs in object-oriented programming, \eg \CC:
 \begin{C++}
 class C {
-	int i, j;
-	int mem() {					$\C{\color{red}// implicit "this" parameter}$
-		i = 1;					$\C{\color{red}// this-{\textgreater}i}$
-		j = 2;					$\C{\color{red}// this-{\textgreater}j}$
+	char c;								$\C{// fields}$
+	int i;
+	double d;
+	int mem() {							$\C{// implicit "this" parameter}$
+		`this->`c; `this->`i; `this->`d;$\C{// access containing fields}$
 	}
 }
 \end{C++}
-Since \CFA is non-object-oriented, the equivalent object-oriented program looks like:
+Nesting of member routines in a \lstinline[language=C++]@class@ allows eliding \lstinline[language=C++]@this->@ because of nested lexical-scoping.
+
+% In object-oriented programming, there is an implicit first parameter, often names @self@ or @this@, which is elided.
+% In any programming language, some functions have a naturally close relationship with a particular data type. 
+% Object-oriented programming allows this close relationship to be codified in the language by making such functions \emph{class methods} of their related data type.
+% Class methods have certain privileges with respect to their associated data type, notably un-prefixed access to the fields of that data type. 
+% When writing C functions in an object-oriented style, this un-prefixed access is swiftly missed, as access to fields of a @Foo* f@ requires an extra three characters @f->@ every time, which disrupts coding flow and clutters the produced code. 
+% 
+% \TODO{Fill out section. Be sure to mention arbitrary expressions in with-blocks, recent change driven by Thierry to prioritize field name over parameters.}
+
+\CFA provides a @with@ clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elided aggregate qualification to fields by opening a scope containing field identifiers.
+Hence, the qualified fields become variables, and making it easier to optimizing field references in a block.
 \begin{cfa}
-struct S { int i, j; };
-int mem( S & `this` ) {			$\C{// explicit "this" parameter}$
-	`this.`i = 1;				$\C{// "this" is not elided}$
-	`this.`j = 2;
+void f( S s ) `with s` {				$\C{// with clause}$
+	c; i; d;							$\C{\color{red}// s.c, s.i, s.d}$
 }
 \end{cfa}
-but it is cumbersome having to write "this." many times in a member.
-
-\CFA provides a @with@ clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elided the "@this.@" by opening a scope containing field identifiers, changing the qualified fields into variables and giving an opportunity for optimizing qualified references.
+and the equivalence for object-style programming is:
 \begin{cfa}
-int mem( S &this ) `with this` { $\C{// with clause}$
-	i = 1;						$\C{\color{red}// this.i}$
-	j = 2;						$\C{\color{red}// this.j}$
+int mem( S & this ) `with this` {		$\C{// with clause}$
+	c; i; d;							$\C{\color{red}// this.c, this.i, this.d}$
 }
 \end{cfa}
-which extends to multiple routine parameters:
+The key generality over the object-oriented approach is that one aggregate parameter \lstinline[language=C++]@this@ is not treated specially over other aggregate parameters:
 \begin{cfa}
 struct T { double m, n; };
-int mem2( S & this1, T & this2 ) `with this1, this2` {
-	i = 1; j = 2;
-	m = 1.0; n = 2.0;
+int mem( S & s, T & t ) `with s, t` {	$\C{// multiple aggregate parameters}$
+	c; i; d;							$\C{\color{red}// s.c, s.i, s.d}$
+	m; n;								$\C{\color{red}// t.m, t.n}$
+}
+\end{cfa}
+The equivalent object-oriented style is:
+\begin{cfa}
+int S::mem( T & t ) {					$\C{// multiple aggregate parameters}$
+	c; i; d;							$\C{\color{red}// this-\textgreater.c, this-\textgreater.i, this-\textgreater.d}$
+	`t.`m; `t.`n;
 }
 \end{cfa}
@@ -1092,7 +1122,7 @@
 	struct S1 { ... } s1;
 	struct S2 { ... } s2;
-	`with s1` {					$\C{// with statement}$
+	`with s1` {						$\C{// with statement}$
 		// access fields of s1 without qualification
-		`with s2` {				$\C{// nesting}$
+		`with s2` {					$\C{// nesting}$
 			// access fields of s1 and s2 without qualification
 		}
@@ -1110,13 +1140,13 @@
 struct T { int i; int k; int m } b, c;
 `with a, b` {
-	j + k;						$\C{// unambiguous, unique names define unique types}$
-	i;							$\C{// ambiguous, same name and type}$
-	a.i + b.i;					$\C{// unambiguous, qualification defines unique names}$
-	m;							$\C{// ambiguous, same name and no context to define unique type}$
-	m = 5.0;					$\C{// unambiguous, same name and context defines unique type}$
-	m = 1;						$\C{// unambiguous, same name and context defines unique type}$
-}
-`with c` { ... }				$\C{// ambiguous, same name and no context}$
-`with (S)c` { ... }				$\C{// unambiguous, same name and cast defines unique type}$
+	j + k;							$\C{// unambiguous, unique names define unique types}$
+	i;								$\C{// ambiguous, same name and type}$
+	a.i + b.i;						$\C{// unambiguous, qualification defines unique names}$
+	m;								$\C{// ambiguous, same name and no context to define unique type}$
+	m = 5.0;						$\C{// unambiguous, same name and context defines unique type}$
+	m = 1;							$\C{// unambiguous, same name and context defines unique type}$
+}
+`with c` { ... }					$\C{// ambiguous, same name and no context}$
+`with (S)c` { ... }					$\C{// unambiguous, same name and cast defines unique type}$
 \end{cfa}
 
@@ -1209,5 +1239,5 @@
 The result of this rule is that any reference can be rebound using the existing pointer assignment semantics by assigning a compatible pointer into the address of the reference, \eg @&r1 = &x;@ above. 
 This rebinding can occur to an arbitrary depth of reference nesting; $n$ address-of operators applied to a reference nested $m$ times will produce an lvalue pointer nested $n$ times if $n \le m$ (note that $n = m+1$ is simply the usual C rvalue address-of operator applied to the $n = m$ case).
-The explicit address-of operators can be thought of as ``cancelling out'' the implicit dereference operators, \eg @(&`*`)r1 = &x@ or @(&(&`*`)`*`)r3 = &(&`*`)r1@ or even @(&`*`)r2 = (&`*`)`*`r3@ for @&r2 = &r3@.
+The explicit address-of operators can be thought of as ``cancelling out'' the implicit dereference operators, \eg @(&`*`)r1 = &x;@ or @(&(&`*`)`*`)r3 = &(&`*`)r1;@ or even @(&`*`)r2 = (&`*`)`*`r3;@ for @&r2 = &r3;@.
 
 Since pointers and references share the same internal representation, code using either is equally performant; in fact the \CFA compiler converts references to pointers internally, and the choice between them in user code can be made based solely on convenience. 
@@ -1224,13 +1254,6 @@
 \end{cfa}
 
-Given that a reference is meant to represent a lvalue, \CFA provides some syntactic shortcuts when initializing references. 
-There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, and return/temporary binding. 
-In each of these contexts, the address-of operator on the target lvalue may (in fact, must) be elided. 
-The syntactic motivation for this is clearest when considering overloaded operator-assignment, \eg @int ?+=?(int &, int)@; given @int x, y@, the expected call syntax is @x += y@, not @&x += y@. 
-
-This initialization of references from lvalues rather than pointers can be considered a ``lvalue-to-reference'' conversion rather than an elision of the address-of operator; similarly, use of a the value pointed to by a reference in an rvalue context can be thought of as a ``reference-to-rvalue'' conversion. 
-\CFA includes one more reference conversion, an ``rvalue-to-reference'' conversion. 
-
-\TODO{finish reference conversions; look at user manual}
+\TODO{Pull more draft text from user manual; make sure to discuss initialization and reference conversions}
+
 
 \subsection{Constructors and Destructors}
@@ -1252,4 +1275,5 @@
 
 \TODO{Some text already at the end of Section~\ref{sec:poly-fns}}
+
 
 \subsection{Units}
