Index: doc/theses/mike_brooks_MMath/background.tex
===================================================================
--- doc/theses/mike_brooks_MMath/background.tex	(revision 2d8299942dbe7aa1ebe645a587876a60f80a9758)
+++ doc/theses/mike_brooks_MMath/background.tex	(revision d3a4986415d3791181de98120031e71a598fe5ce)
@@ -45,23 +45,26 @@
 Hence, in all cases, @sizeof@ is informing about type information.
 
-So, thinking of an array as a pointer to its first element is too simplistic an analogue and it is not backed up the type system.
-This misguided analogue can be forced onto single-dimension arrays but there is no advantage other than possibly teaching beginning programmers about basic runtime array-access.
-
-Continuing, a shortened form for declaring local variables exists, provided that length information is given in the initializer:
+So, thinking of an array as a pointer to its first element is too simplistic an analogue and it is not backed up by the type system.
+This misguided analogue works for a single-dimension array but there is no advantage other than possibly teaching beginning programmers about basic runtime array-access.
+
+Continuing, a short form for declaring array variables exists using length information provided implicitly by an initializer.
 \lstinput{59-62}{bkgd-carray-arrty.c}
-In these declarations, the resulting types are both arrays, but their lengths are inferred.
-
-My contribution is enabled by recognizing
+The compiler counts the number of initializer elements and uses this value as the first dimension.
+Unfortunately, the implicit element counting does not extend to dimensions beyond the first.
+\lstinput{64-67}{bkgd-carray-arrty.c}
+
+My contribution is recognizing:
 \begin{itemize}
-	\item There is value in using a type that knows how big the whole thing is.
+	\item There is value in using a type that knows its size.
 	\item The type pointer to (first) element does not.
 	\item C \emph{has} a type that knows the whole picture: array, e.g. @T[10]@.
-	\item This type has all the usual derived forms, which also know the whole picture.  A usefully noteworthy example is pointer to array, e.g. @T(*)[10]@.
+	\item This type has all the usual derived forms, which also know the whole picture.
+	A usefully noteworthy example is pointer to array, e.g. @T (*)[10]@.\footnote{
+	The parenthesis are necessary because subscript has higher priority than pointer in C declarations.
+	(Subscript also has higher priority than dereference in C expressions.)}
 \end{itemize}
 
-Each of these sections, which introduces another layer of of the C arrays' story,
-concludes with an \emph{Unfortunate Syntactic Reference}.
-It shows how to spell the types under discussion,
-along with interactions with orthogonal (but easily confused) language features.
+The following sections introduce the many layers of the C array story, concluding with an \emph{Unfortunate Syntactic Reference}.
+It shows how to define (spell) the types under discussion, along with interactions with orthogonal (but easily confused) language features.
 Alternate spellings are listed within a row.
 The simplest occurrences of types distinguished in the preceding discussion are marked with $\triangleright$.
@@ -78,7 +81,40 @@
 for the example of letting @x@ be a \emph{pointer to array}, the declaration is spelled:
 \begin{cfa}
-[ * [10] T ] x;
+* [10] T x;
 \end{cfa}
 The \CFA-Full column gives the spelling of a different type, introduced in TODO, which has all of my contributed improvements for safety and ergonomics.
+
+Another example of confusion results from the fact that a routine name and its parameters are embedded within the return type, mimicking the way the return value is used at the routine's call site.
+For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
+\begin{cfa}
+int @(*@f@())[@5@]@ {...}; $\C{// definition}$
+ ... @(*@f@())[@3@]@ += 1; $\C{// usage}$
+\end{cfa}
+Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
+While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice, even though Dennis Richie believed otherwise:
+\begin{quote}
+In spite of its difficulties, I believe that the C's approach to declarations remains plausible, and am comfortable with it; it is a useful unifying principle.~\cite[p.~12]{Ritchie93}
+\end{quote}
+
+\CFA provides its own type, variable and routine declarations, using a different syntax.
+The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
+In the following example, {\color{red}red} is the base type and {\color{blue}blue} is qualifiers.
+The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C}}	& \multicolumn{1}{c}{\textbf{\CFA}}	\\
+\begin{cfa}[moredelim={**[is][\color{blue}]{\#}{\#}}]
+@int@ #*# x1 #[5]#;
+@int@ #(*#x2#)[5]#;
+#int (*#f@( int p )@#)[5]#;
+\end{cfa}
+&
+\begin{cfa}[moredelim={**[is][\color{blue}]{\#}{\#}}]
+#[5] *# @int@ x1;
+#* [5]# @int@ x2;
+#[* [5] int]# f@( int p )@;
+\end{cfa}
+\end{tabular}
+\end{cquote}
 
 \VRef[Figure]{bkgd:ar:usr:avp} gives this reference for the discussion so far.
@@ -87,90 +123,39 @@
 \centering
 \setlength{\tabcolsep}{3pt}
-\begin{tabular}{llllll}
-	& Description & Type & Declaration & \CFA-C  & \CFA-Full \\ \hline
-	$\triangleright$ & val.
-	    & @T@ 
-	    & @T x;@ 
-	    & @[ T ]@
-	    & 
-	    \\ \hline
-	& \pbox{20cm}{ \vspace{2pt} val.\\ \footnotesize{no writing the val.\ in \lstinline{x}}   }\vspace{2pt}
-	    & \pbox{20cm}{ \vspace{2pt} \lstinline{const T} \\ \lstinline{T const}   }
-	    & \pbox{20cm}{ \vspace{2pt} \lstinline{const T x;} \\ \lstinline{T const x;}   }
-	    & @[ const T ]@
-	    & 
-	    \\ \hline \hline
-	$\triangleright$ & ptr.\ to val.
-	    & @T *@ 
-	    & @T * x;@ 
-	    & @[ * T ]@
-	    &
-	    \\ \hline
-	& \pbox{20cm}{ \vspace{2pt} ptr.\ to val.\\ \footnotesize{no writing the ptr.\ in \lstinline{x}}   }\vspace{2pt}
-	    & @T * const@ 
-	    & @T * const x;@ 
-	    & @[ const * T ]@
-	    & 
-	    \\ \hline
-	& \pbox{20cm}{ \vspace{2pt} ptr.\ to val.\\ \footnotesize{no writing the val.\ in \lstinline{*x}}   }\vspace{2pt}
-	    & \pbox{20cm}{ \vspace{2pt} \lstinline{const T *} \\ \lstinline{T const *}   }
-	    & \pbox{20cm}{ \vspace{2pt} \lstinline{const T * x;} \\ \lstinline{T const * x;}   }
-	    & @[ * const T ]@
-	    & 
-	    \\ \hline \hline
-	$\triangleright$ & ar.\ of val.
-	    & @T[10]@ 
-	    & @T x[10];@ 
-	    & @[ [10] T ]@
-	    & @[ array(T, 10) ]@
-	    \\ \hline
-	& \pbox{20cm}{ \vspace{2pt} ar.\ of val.\\ \footnotesize{no writing the val.\ in \lstinline{x[5]}}   }\vspace{2pt}
-	    & \pbox{20cm}{ \vspace{2pt} \lstinline{const T[10]} \\ \lstinline{T const[10]}   }
-	    & \pbox{20cm}{ \vspace{2pt} \lstinline{const T x[10];} \\ \lstinline{T const x[10];}   }
-	    & @[ [10] const T ]@
-	    & @[ const array(T, 10) ]@
-	    \\ \hline
-	& ar.\ of ptr.\ to val.
-	    & @T*[10]@
-	    & @T *x[10];@
-	    & @[ [10] * T ]@
-	    & @[ array(* T, 10) ]@
-	    \\ \hline
-	& \pbox{20cm}{ \vspace{2pt} ar.\ of ptr.\ to val.\\ \footnotesize{no writing the ptr.\ in \lstinline{x[5]}}   }\vspace{2pt}
-	    & @T * const [10]@ 
-	    & @T * const x[10];@ 
-	    & @[ [10] const * T ]@
-	    & @[ array(const * T, 10) ]@
-	    \\ \hline
-	& \pbox{20cm}{ \vspace{2pt} ar.\ of ptr.\ to val.\\ \footnotesize{no writing the val.\ in \lstinline{*(x[5])}}   }\vspace{2pt}
-	    & \pbox{20cm}{ \vspace{2pt} \lstinline{const T * [10]} \\ \lstinline{T const * [10]}   }
-	    & \pbox{20cm}{ \vspace{2pt} \lstinline{const T * x[10];} \\ \lstinline{T const * x[10];}   }
-	    & @[ [10] * const T ]@
-	    & @[ array(* const T, 10) ]@
-	    \\ \hline \hline
-	$\triangleright$ & ptr.\ to ar.\ of val.
-	    & @T(*)[10]@
-	    & @T (*x)[10];@
-	    & @[ * [10] T ]@
-	    & @[ * array(T, 10) ]@
-	    \\ \hline
-	& \pbox{20cm}{ \vspace{2pt} ptr.\ to ar.\ of val.\\ \footnotesize{no writing the ptr.\ in \lstinline{x}}   }\vspace{2pt}
-	    & @T(* const)[10]@
-	    & @T (* const x)[10];@
-	    & @[ const * [10] T ]@
-	    & @[ const * array(T, 10) ]@
-	    \\ \hline
-	& \pbox{20cm}{ \vspace{2pt} ptr.\ to ar.\ of val.\\ \footnotesize{no writing the val.\ in \lstinline{(*x)[5]}}   }\vspace{2pt}
-	    & \pbox{20cm}{ \vspace{2pt} \lstinline{const T(*)[10]} \\ \lstinline{T const (*) [10]}   }
-	    & \pbox{20cm}{ \vspace{2pt} \lstinline{const T (*x)[10];} \\ \lstinline{T const (*x)[10];}   }
-	    & @[ * [10] const T ]@
-	    & @[ * const array(T, 10) ]@
-	    \\ \hline
-	& ptr.\ to ar.\ of ptr.\ to val.
-	    & @T*(*)[10]@
-	    & @T *(*x)[10];@
-	    & @[ * [10] * T ]@
-	    & @[ * array(* T, 10) ]@
-	    \\ \hline
+\begin{tabular}{ll|l|l|l|l}
+	& Description & Type & Declaration & \CFA  & \CFA-thesis \\ \hline
+	$\triangleright$ & val. & @T@ & @T x;@ & @T@ & \\
+	\hline
+	& immutable val. & @const T@ & @T const x;@ & @const T@ & \\
+	& & @T const@ & @T const x;@ & @T const@ & \\
+	\hline \hline
+	$\triangleright$ & ptr.\ to val. & @T *@ & @T * x;@ & @* T@ & \\
+	\hline
+	& immutable ptr. to val. & @T * const@ & @T * const x;@ & @const * T@ & \\
+	\hline
+	& ptr. to immutable val. & @const T *@ & @const T * x;@ & @* const T@ & \\
+	& & @T const *@ & @T const * x;@ & @* T const@ & \\
+	\hline \hline
+	$\triangleright$ & ar.\ of val. & @T[10]@ & @T x[10];@ & @[10] T@ & @array(T, 10)@ \\
+	\hline
+	& ar.\ of immutable val. & @const T[10]@ & @const T x[10];@ & @[10] const T@ & @const array(T, 10)@ \\
+    & & @T const [10]@ & @T const x[10];@ & @[10] T const@ & @array(T, 10) const@ \\
+	\hline
+	& ar.\ of ptr.\ to val. & @T * [10]@ & @T * x[10];@ & @[10] * T@ & @array(T * | * T, 10)@ \\
+	\hline
+	& ar.\ of imm. ptr.\ to val. & @T * const [10]@ & @T * const x[10];@ & @[10] const * T@ & @array(const * T, 10)@ \\
+	\hline
+	& ar.\ of ptr.\ to imm. val. & @const T * [10]@ & @const T * x[10];@ & @[10] * const T@ & @array(* const T, 10)@ \\
+	& & @T const * [10]@ & @T const * x[10];@ & @[10] * T const@ & @array(* T const, 10)@ \\
+	\hline \hline
+	$\triangleright$ & ptr.\ to ar.\ of val. & @T(*)[10]@ & @T (*x)[10];@ & @* [10] T@ & @* array(T, 10)@ \\
+	\hline
+	& imm. ptr.\ to ar.\ of val. & @T(* const)[10]@ & @T (* const x)[10];@ & @const * [10] T@ & @const * array(T, 10)@ \\
+	\hline
+	& ptr.\ to ar.\ of imm. val. & @const T(*)[10]@ & @const T (*x)[10];@ & @* [10] const T@ & @* const array(T, 10)@ \\
+	& & @T const (*) [10]}@ & @T const (*x)[10];@ & @* [10] T const@ & @* array(T, 10) const@ \\
+	\hline
+	& ptr.\ to ar.\ of ptr.\ to val. & @T*(*)[10]@ & @T *(*x)[10];@ & @* [10] * T@ & @* array(T * | * T, 10)@ \\
+	\hline
 \end{tabular}
 \caption{Unfortunate Syntactic Reference for Array vs Pointer.  Includes interaction with constness.}
@@ -251,5 +236,5 @@
 ARM-6.7.6.3.7 explains that when an array type is written for a parameter,
 the parameter's type becomes a type that I summarize as being the array-decayed type.
-The respective handlings of the following two parameter spellings shows that the array-spelled one is really, like the other, a pointer.
+The respective handling of the following two parameter spellings shows that the array-spelled one is really, like the other, a pointer.
 \lstinput{12-16}{bkgd-carray-decay.c}
 As the @sizeof(x)@ meaning changed, compared with when run on a similarly-spelled local variable declaration,
@@ -284,5 +269,5 @@
 \lstinput{32-42}{bkgd-carray-decay.c}
 
-\VRef[Figure]{bkgd:ar:usr:decay-parm} gives the reference for the decay phenomenon seen in parameter decalarations.
+\VRef[Figure]{bkgd:ar:usr:decay-parm} gives the reference for the decay phenomenon seen in parameter declarations.
 
 \begin{figure}
Index: doc/theses/mike_brooks_MMath/programs/bkgd-carray-arrty.c
===================================================================
--- doc/theses/mike_brooks_MMath/programs/bkgd-carray-arrty.c	(revision 2d8299942dbe7aa1ebe645a587876a60f80a9758)
+++ doc/theses/mike_brooks_MMath/programs/bkgd-carray-arrty.c	(revision d3a4986415d3791181de98120031e71a598fe5ce)
@@ -57,9 +57,13 @@
 	f( &ar );
 
-	float fs[] = {3.14, 1.707};
+	float fs[] = {3.14, 1.77};
 	char cs[] = "hello";
 	static_assert( sizeof(fs) == 2 * sizeof(float) );
 	static_assert( sizeof(cs) == 6 * sizeof(char) );  $\C{// 5 letters + 1 null terminator}$
 
+	float fm[][2] = { {3.14, 1.77}, {12.4, 0.01}, {7.8, 1.23} };  $\C{// brackets define structuring}$
+	char cm[][sizeof("hello")] = { "hello", "hello", "hello" };
+	static_assert( sizeof(fm) == 3 * 2 * sizeof(float) );
+	static_assert( sizeof(cm) == 3 * 6 * sizeof(char) );
 }