Index: doc/theses/jiada_liang_MMath/background.tex
===================================================================
--- doc/theses/jiada_liang_MMath/background.tex	(revision 4c8f29ff2e86251e35ad101e72e33e8514c571d4)
+++ doc/theses/jiada_liang_MMath/background.tex	(revision 736a38dedf9b0e28de1be78317e94889af77d502)
@@ -1,6 +1,8 @@
 \chapter{Background}
 
+\vspace*{-8pt}
+
 \CFA is a backwards-compatible extension of the C programming language, therefore, it must support C-style enumerations.
-The following covers C enumerations.
+The following discussion covers C enumerations.
 
 As discussed in \VRef{s:Aliasing}, it is common for C programmers to ``believe'' there are three equivalent forms of named constants.
@@ -16,5 +18,5 @@
 \item
 The same explicit management is true for the @const@ declaration, and the @const@ variable cannot appear in constant-expression locations, like @case@ labels, array dimensions,\footnote{
-C allows variable-length array-declarations (VLA), so this case does work, but it fails in \CC, which does not support VLAs, unless it is \lstinline{g++}.} immediate operands of assembler instructions, and occupy storage.
+C allows variable-length array-declarations (VLA), so this case does work, but it fails in \CC, which does not support VLAs, unless it is \lstinline{g++}.} immediate oper\-ands of assembler instructions, and occupy storage.
 \begin{clang}
 $\$$ nm test.o
@@ -22,5 +24,5 @@
 \end{clang}
 \item
-Only the @enum@ form is managed by the compiler, is part of the language type-system, works in all C constant-expression locations, and might not occupy storage..
+Only the @enum@ form is managed by the compiler, is part of the language type-system, works in all C constant-expression locations, and normally does not occupy storage.
 \end{enumerate}
 
@@ -30,19 +32,30 @@
 
 C can simulate the aliasing @const@ declarations \see{\VRef{s:Aliasing}}, with static and dynamic initialization.
+\begin{cquote}
+\begin{tabular}{@{}l@{}l@{}}
+\multicolumn{1}{@{}c@{}}{\textbf{static initialization}} &  \multicolumn{1}{c@{}}{\textbf{dynamic intialization}} \\
 \begin{clang}
-static const int one = 0 + 1;			$\C{// static initialization}$
+static const int one = 0 + 1;
 static const void * NIL = NULL;
 static const double PI = 3.14159;
 static const char Plus = '+';
 static const char * Fred = "Fred";
-static const int Mon = 0, Tue = Mon + 1, Wed = Tue + 1, Thu = Wed + 1, Fri = Thu + 1,
-					Sat = Fri + 1, Sun = Sat + 1;
+static const int Mon = 0, Tue = Mon + 1, Wed = Tue + 1,
+	Thu = Wed + 1, Fri = Thu + 1, Sat = Fri + 1, Sun = Sat + 1;
+\end{clang}
+&
+\begin{clang}
 void foo() {
-	const int r = random() % 100;		$\C{// dynamic intialization}$
-	int va[r];							$\C{// VLA, auto scope only}$
+	// auto scope only
+	const int r = random() % 100;
+	int va[r];
 }
+
+
 \end{clang}
-Statically initialized identifiers may appear in any constant-expression context, \eg @case@.
-Dynamically initialized identifiers may appear as array dimensions in @g++@, which allows variable-sized arrays on the stack.
+\end{tabular}
+\end{cquote}
+However, statically initialized identifiers can not appear in constant-expression contexts, \eg @case@.
+Dynamically initialized identifiers may appear in initialization and array dimensions in @g++@, which allows variable-sized arrays on the stack.
 Again, this form of aliasing is not an enumeration.
 
@@ -82,13 +95,13 @@
 The enumerators are rvalues, so assignment is disallowed.
 Finally, enumerators are \newterm{unscoped}, \ie enumerators declared inside of an @enum@ are visible (projected) into the enclosing scope of the @enum@ type.
-For unnamed enumeration this semantic is required because there is no type name for scoped qualification.
+For unnamed enumerations, this semantic is required because there is no type name for scoped qualification.
 
 As noted, this kind of aliasing declaration is not an enumeration, even though it is declared using an @enum@ in C.
 While the semantics is misleading, this enumeration form matches with aggregate types:
 \begin{cfa}
-typedef struct /* unnamed */  { ... } S;
-struct /* unnamed */  { ... } x, y, z;	$\C{// questionable}$
+typedef struct @/* unnamed */@  { ... } S;
+struct @/* unnamed */@  { ... } x, y, z;	$\C{// questionable}$
 struct S {
-	union /* unnamed */ {				$\C{// unscoped fields}$
+	union @/* unnamed */@ {					$\C{// unscoped fields}$
 		int i;  double d ;  char ch;
 	};
@@ -132,5 +145,5 @@
 @week = 10000;@						$\C{// UNDEFINED! implicit conversion to Week}$
 \end{clang}
-While converting an enumerator to underlying type is useful, the implicit conversion from the base type to an enumeration type is a common source of error.
+While converting an enumerator to its underlying type is useful, the implicit conversion from the base type to an enumeration type is a common source of error.
 
 Enumerators can appear in @switch@ and looping statements.
@@ -143,13 +156,14 @@
 		printf( "weekend\n" );
 }
-for ( enum Week day = Mon; day <= Sun; day += 1 ) {
+for ( enum Week day = Mon; day <= Sun; day += 1 ) { // step of 1
 	printf( "day %d\n", day ); // 0-6
 }
 \end{cfa}
-For iterating, the enumerator values \emph{must} have a consecutive ordering with a fixed step between values.
+For iterating to make sense, the enumerator values \emph{must} have a consecutive ordering with a fixed step between values.
+For example, a gap introduced by @Thu = 10@, results in iterating over the values 0--13, where values 3--9 are not @Week@ values.
 Note, it is the bidirectional conversion that allows incrementing @day@: @day@ is converted to @int@, integer @1@ is added, and the result is converted back to @Week@ for the assignment to @day@.
 For safety, \CC does not support the bidirectional conversion, and hence, an unsafe cast is necessary to increment @day@: @day = (Week)(day + 1)@.
 
-There is a C idiom to automatically know the number of enumerators in an enumeration.
+There is a C idiom to automatically compute the number of enumerators in an enumeration.
 \begin{cfa}
 enum E { A, B, C, D, @N@ };  // N == 4
@@ -183,3 +197,3 @@
 
 \bigskip
-While C provides a true enumeration, it is restricted, has unsafe semantics, and does provide enumeration features in other programming languages.
+While C provides a true enumeration, it is restricted, has unsafe semantics, and does provide useful enumeration features in other programming languages.