Index: doc/theses/mike_brooks_MMath/array.tex
===================================================================
--- doc/theses/mike_brooks_MMath/array.tex	(revision f5fbcad9ad237a0048b97ebd60a0779312fec49c)
+++ doc/theses/mike_brooks_MMath/array.tex	(revision 82e5670b382ce297cad720a0ac24ccb659cdb8f1)
@@ -510,2 +510,67 @@
 
 \subsection{Retire pointer arithmetic}
+
+
+\section{\CFA}
+
+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \\
+moved from background chapter \\
+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \\
+
+Traditionally, fixing C meant leaving the C-ism alone, while providing a better alternative beside it.
+(For later:  That's what I offer with array.hfa, but in the future-work vision for arrays, the fix includes helping programmers stop accidentally using a broken C-ism.)
+
+\subsection{\CFA features interacting with arrays}
+
+Prior work on \CFA included making C arrays, as used in C code from the wild,
+work, if this code is fed into @cfacc@.
+The quality of this this treatment was fine, with no more or fewer bugs than is typical.
+
+More mixed results arose with feeding these ``C'' arrays into preexisting \CFA features.
+
+A notable success was with the \CFA @alloc@ function,
+which type information associated with a polymorphic return type
+replaces @malloc@'s use of programmer-supplied size information.
+\begin{cfa}
+// C, library
+void * malloc( size_t );
+// C, user
+struct tm * el1 = malloc(      sizeof(struct tm) );
+struct tm * ar1 = malloc( 10 * sizeof(struct tm) );
+
+// CFA, library
+forall( T * ) T * alloc();
+// CFA, user
+tm * el2 = alloc();
+tm (*ar2)[10] = alloc();
+\end{cfa}
+The alloc polymorphic return compiles into a hidden parameter, which receives a compiler-generated argument.
+This compiler's argument generation uses type information from the left-hand side of the initialization to obtain the intended type.
+Using a compiler-produced value eliminates an opportunity for user error.
+
+TODO: fix in following: even the alloc call gives bad code gen: verify it was always this way; walk back the wording about things just working here; assignment (rebind) seems to offer workaround, as in bkgd-cfa-arrayinteract.cfa
+
+Bringing in another \CFA feature, reference types, both resolves a sore spot of the last example, and gives a first example of an array-interaction bug.
+In the last example, the choice of ``pointer to array'' @ar2@ breaks a parallel with @ar1@.
+They are not subscripted in the same way.
+\begin{cfa}
+ar1[5];
+(*ar2)[5];
+\end{cfa}
+Using ``reference to array'' works at resolving this issue.  TODO: discuss connection with Doug-Lea \CC proposal.
+\begin{cfa}
+tm (&ar3)[10] = *alloc();
+ar3[5];
+\end{cfa}
+The implicit size communication to @alloc@ still works in the same ways as for @ar2@.
+
+Using proper array types (@ar2@ and @ar3@) addresses a concern about using raw element pointers (@ar1@), albeit a theoretical one.
+TODO xref C standard does not claim that @ar1@ may be subscripted,
+because no stage of interpreting the construction of @ar1@ has it be that ``there is an \emph{array object} here.''
+But both @*ar2@ and the referent of @ar3@ are the results of \emph{typed} @alloc@ calls,
+where the type requested is an array, making the result, much more obviously, an array object.
+
+The ``reference to array'' type has its sore spots too.
+TODO see also @dimexpr-match-c/REFPARAM_CALL@ (under @TRY_BUG_1@)
+
+TODO: I fixed a bug associated with using an array as a T.  I think.  Did I really?  What was the bug?