Index: doc/theses/jiada_liang_MMath/CEnum.tex
===================================================================
--- doc/theses/jiada_liang_MMath/CEnum.tex	(revision 92a0ee810313b2b928368cc598624cc69027a7de)
+++ 	(revision )
@@ -1,130 +1,0 @@
-\chapter{C Enumeration in \CFA}
-
-\CFA supports legacy C enumeration using the same syntax for backwards compatibility.
-A C-style enumeration in \CFA is called a \newterm{C Enum}.
-The semantics of the C Enum is mostly consistent with C with some restrictions.
-The following sections detail all of my new contributions to enumerations in C.
-
-
-\section{Visibility}
-\label{s:CVisibility}
-
-In C, unscoped enumerators present a \newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names.
-\begin{cfa}
-enum E1 { First, Second, Third, Fourth };
-enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$
-\end{cfa}
-There is no mechanism in C to resolve these naming conflicts other than renaming one of the duplicates, which may be impossible if the conflict comes from system include files.
-
-The \CFA type-system allows extensive overloading, including enumerators.
-Hence, most ambiguities among C enumerators are implicitly resolved by the \CFA type system, possibly without any programmer knowledge of the conflict.
-In addition, C Enum qualification is added, exactly like aggregate field-qualification, to disambiguate.
-\VRef[Figure]{f:EnumeratorVisibility} shows how resolution, qualification, and casting are used to disambiguate situations for enumerations @E1@ and @E2@.
-
-\begin{figure}
-\begin{cfa}
-E1 f() { return Third; }				$\C{// overload functions with different return types}$
-E2 f() { return Fourth; }
-void g( E1 e );
-void h( E2 e );
-void foo() {							$\C{// different resolutions and dealing with ambiguities}$
-	E1 e1 = First;   E2 e2 = First;		$\C{// initialization}$
-	e1 = Second;   e2 = Second;			$\C{// assignment}$
-	e1 = f();   e2 = f();				$\C{// function return}$
-	g( First );   h( First );			$\C{// function argument}$
-	int i = @E1.@First + @E2.@First;	$\C{// disambiguate with qualification}$
-	int j = @(E1)@First + @(E2)@First;	$\C{// disambiguate with cast}$
-}
-\end{cfa}
-\caption{Enumerator Visibility and Disambiguating}
-\label{f:EnumeratorVisibility}
-\end{figure}
-
-
-\section{Scoping}
-
-A C Enum can be scoped, using @'!'@, so the enumerator constants are not projected into the enclosing scope.
-\begin{cfa}
-enum Week @!@ { Mon, Tue, Wed, Thu = 10, Fri, Sat, Sun };
-enum RGB @!@ { Red, Green, Blue };
-\end{cfa}
-Now the enumerators \emph{must} be qualified with the associated enumeration type.
-\begin{cfa}
-Week week = @Week.@Mon;
-week = @Week.@Sat;
-RGB rgb = @RGB.@Red;
-rgb = @RGB.@Blue;
-\end{cfa}
-% with feature unimplemented
-It is possible to toggle back to unscoped using the \CFA @with@ auto-qualification clause/statement (see also \CC \lstinline[language=c++]{using enum} in Section~\ref{s:C++RelatedWork}).
-\begin{cfa}
-with ( @Week@, @RGB@ ) {				$\C{// type names}$
-	 week = @Sun@;						$\C{// no qualification}$
-	 rgb = @Green@;
-}
-\end{cfa}
-As in Section~\ref{s:CVisibility}, opening multiple scoped enumerations in a @with@ can result in duplicate enumeration names, but \CFA implicit type resolution and explicit qualification/casting handle this localized scenario.
-
-A partially implemented extension to enumerator scoping is providing a combination of scoped and unscoped enumerators, using individual denotations, where @'^'@ means unscoped.
-\begin{cfa}
-enum E1 { @!@A, @^@B, C };
-enum E2 @!@ { @!@A, @^@B, C };
-\end{cfa}
-For @E1@, @A@ is scoped; @B@ and @C@ are unscoped.
-For @E2@, @A@ and @C@ are scoped; @B@ is unscoped.
-Finding a use case is important to justify completing this extension.
-
-
-\section{Type Safety}
-
-As in Section~\ref{s:Usage}, C's implicit bidirectional conversion between enumeration and integral type raises a safety concern.
-In \CFA, the conversion is changed to unidirectional: an enumeration can be implicitly converted into an integral type, with an associated @safe@ conversion cost.
-But an integral type cannot be implicitly converted into a C enumeration because the conversion cost is set to @infinity@.
-\begin{cfa}
-enum Bird { Penguin, Robin, Eagle };
-enum Fish { Shark, Salmon, Whale };
-
-int i = Robin;							$\C{// allow, implicitly converts to 1}$
-enum Bird @bird = 1;@					$\C{// disallow }$
-enum Bird @bird = Shark;@				$\C{// disallow }$
-\end{cfa}
-It is now up to the programmer to insert an explicit cast to force the assignment.
-\begin{cfa}
-enum Bird bird = @(Bird)@1;
-enum Bird bird = @(Bird)@Shark
-\end{cfa}
-
-Note, \CC has the same safe restriction~\cite[C.1.5.7.2]{C++} and provides the same workaround cast.
-\begin{description}[parsep=0pt]
-\item[Change:] \CC objects of enumeration type can only be assigned values of the same enumeration type.
-In C, objects of enumeration type can be assigned values of any integral type.
-Example:
-\begin{cfa}
-enum color { red, blue, green };
-color c = 1;				$\C{// valid C, invalid \CC}$
-\end{cfa}
-\item[Rationale:] The type-safe nature of \CC.
-\item[Effect on original feature:] Deletion of semantically well-defined feature.
-\item[Difficulty of converting:] Syntactic transformation. (The type error produced by the assignment can be
-automatically corrected by applying an explicit cast.)
-\item[How widely used:] Common.
-\end{description}
-
-\begin{comment}
-\begin{description}[parsep=0pt]
-\item[Change:] In \CC, the type of an enumerator is its enumeration.
-In C, the type of an enumerator is @int@.
-Example:
-\begin{cfa}
-enum e { A };
-sizeof(A) == sizeof(int)	$\C{// in C}$
-sizeof(A) == sizeof(e)		$\C{// in \CC}$
-/* and sizeof(int) is not necessary equal to sizeof(e) */
-\end{cfa}
-\item[Rationale:] In \CC, an enumeration is a distinct type.
-\item[Effect on original feature:] Change to semantics of well-defined feature.
-\item[Difficulty of converting:] Semantic transformation.
-\item[How widely used:] Seldom. The only time this affects existing C code is when the size of an enumerator is
-taken. Taking the size of an enumerator is not a common C coding practice.
-\end{description}
-\end{comment}
Index: doc/theses/jiada_liang_MMath/CFAenum.tex
===================================================================
--- doc/theses/jiada_liang_MMath/CFAenum.tex	(revision 92a0ee810313b2b928368cc598624cc69027a7de)
+++ doc/theses/jiada_liang_MMath/CFAenum.tex	(revision b0069a30901fd809ec219ff7ac4592aff6c44ac1)
@@ -1,3 +1,3 @@
-\chapter{\CFA Enumeration}
+\chapter{\texorpdfstring{\CFA}{Cforall} Enumeration}
 
 \CFA extends C-Style enumeration by adding a number of new features that bring enumerations inline with other modern programming languages.
@@ -59,4 +59,5 @@
 The label and value of an enumerator is stored in a global data structure for each enumeration, where attribute functions @label@/@value@ map an \CFA enumeration object to the corresponding data.
 These operations do not apply to C Enums because backwards compatibility means the necessary backing data structures cannot be supplied.
+
 
 \section{Opaque Enumeration}
Index: doc/theses/jiada_liang_MMath/Cenum.tex
===================================================================
--- doc/theses/jiada_liang_MMath/Cenum.tex	(revision b0069a30901fd809ec219ff7ac4592aff6c44ac1)
+++ doc/theses/jiada_liang_MMath/Cenum.tex	(revision b0069a30901fd809ec219ff7ac4592aff6c44ac1)
@@ -0,0 +1,130 @@
+\chapter{C Enumeration in \texorpdfstring{\CFA}{Cforall}}
+
+\CFA supports legacy C enumeration using the same syntax for backwards compatibility.
+A C-style enumeration in \CFA is called a \newterm{C Enum}.
+The semantics of the C Enum is mostly consistent with C with some restrictions.
+The following sections detail all of my new contributions to enumerations in C.
+
+
+\section{Visibility}
+\label{s:CVisibility}
+
+In C, unscoped enumerators present a \newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names.
+\begin{cfa}
+enum E1 { First, Second, Third, Fourth };
+enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$
+\end{cfa}
+There is no mechanism in C to resolve these naming conflicts other than renaming one of the duplicates, which may be impossible if the conflict comes from system include files.
+
+The \CFA type-system allows extensive overloading, including enumerators.
+Hence, most ambiguities among C enumerators are implicitly resolved by the \CFA type system, possibly without any programmer knowledge of the conflict.
+In addition, C Enum qualification is added, exactly like aggregate field-qualification, to disambiguate.
+\VRef[Figure]{f:EnumeratorVisibility} shows how resolution, qualification, and casting are used to disambiguate situations for enumerations @E1@ and @E2@.
+
+\begin{figure}
+\begin{cfa}
+E1 f() { return Third; }				$\C{// overload functions with different return types}$
+E2 f() { return Fourth; }
+void g( E1 e );
+void h( E2 e );
+void foo() {							$\C{// different resolutions and dealing with ambiguities}$
+	E1 e1 = First;   E2 e2 = First;		$\C{// initialization}$
+	e1 = Second;   e2 = Second;			$\C{// assignment}$
+	e1 = f();   e2 = f();				$\C{// function return}$
+	g( First );   h( First );			$\C{// function argument}$
+	int i = @E1.@First + @E2.@First;	$\C{// disambiguate with qualification}$
+	int j = @(E1)@First + @(E2)@First;	$\C{// disambiguate with cast}$
+}
+\end{cfa}
+\caption{Enumerator Visibility and Disambiguating}
+\label{f:EnumeratorVisibility}
+\end{figure}
+
+
+\section{Scoping}
+
+A C Enum can be scoped, using @'!'@, so the enumerator constants are not projected into the enclosing scope.
+\begin{cfa}
+enum Week @!@ { Mon, Tue, Wed, Thu = 10, Fri, Sat, Sun };
+enum RGB @!@ { Red, Green, Blue };
+\end{cfa}
+Now the enumerators \emph{must} be qualified with the associated enumeration type.
+\begin{cfa}
+Week week = @Week.@Mon;
+week = @Week.@Sat;
+RGB rgb = @RGB.@Red;
+rgb = @RGB.@Blue;
+\end{cfa}
+% with feature unimplemented
+It is possible to toggle back to unscoped using the \CFA @with@ auto-qualification clause/statement (see also \CC \lstinline[language=c++]{using enum} in Section~\ref{s:C++RelatedWork}).
+\begin{cfa}
+with ( @Week@, @RGB@ ) {				$\C{// type names}$
+	 week = @Sun@;						$\C{// no qualification}$
+	 rgb = @Green@;
+}
+\end{cfa}
+As in Section~\ref{s:CVisibility}, opening multiple scoped enumerations in a @with@ can result in duplicate enumeration names, but \CFA implicit type resolution and explicit qualification/casting handle this localized scenario.
+
+A partially implemented extension to enumerator scoping is providing a combination of scoped and unscoped enumerators, using individual denotations, where @'^'@ means unscoped.
+\begin{cfa}
+enum E1 { @!@A, @^@B, C };
+enum E2 @!@ { @!@A, @^@B, C };
+\end{cfa}
+For @E1@, @A@ is scoped; @B@ and @C@ are unscoped.
+For @E2@, @A@ and @C@ are scoped; @B@ is unscoped.
+Finding a use case is important to justify completing this extension.
+
+
+\section{Type Safety}
+
+As in Section~\ref{s:Usage}, C's implicit bidirectional conversion between enumeration and integral type raises a safety concern.
+In \CFA, the conversion is changed to unidirectional: an enumeration can be implicitly converted into an integral type, with an associated @safe@ conversion cost.
+But an integral type cannot be implicitly converted into a C enumeration because the conversion cost is set to @infinity@.
+\begin{cfa}
+enum Bird { Penguin, Robin, Eagle };
+enum Fish { Shark, Salmon, Whale };
+
+int i = Robin;							$\C{// allow, implicitly converts to 1}$
+enum Bird @bird = 1;@					$\C{// disallow }$
+enum Bird @bird = Shark;@				$\C{// disallow }$
+\end{cfa}
+It is now up to the programmer to insert an explicit cast to force the assignment.
+\begin{cfa}
+enum Bird bird = @(Bird)@1;
+enum Bird bird = @(Bird)@Shark
+\end{cfa}
+
+Note, \CC has the same safe restriction~\cite[C.1.5.7.2]{C++} and provides the same workaround cast.
+\begin{description}[parsep=0pt]
+\item[Change:] \CC objects of enumeration type can only be assigned values of the same enumeration type.
+In C, objects of enumeration type can be assigned values of any integral type.
+Example:
+\begin{cfa}
+enum color { red, blue, green };
+color c = 1;				$\C{// valid C, invalid \CC}$
+\end{cfa}
+\item[Rationale:] The type-safe nature of \CC.
+\item[Effect on original feature:] Deletion of semantically well-defined feature.
+\item[Difficulty of converting:] Syntactic transformation. (The type error produced by the assignment can be
+automatically corrected by applying an explicit cast.)
+\item[How widely used:] Common.
+\end{description}
+
+\begin{comment}
+\begin{description}[parsep=0pt]
+\item[Change:] In \CC, the type of an enumerator is its enumeration.
+In C, the type of an enumerator is @int@.
+Example:
+\begin{cfa}
+enum e { A };
+sizeof(A) == sizeof(int)	$\C{// in C}$
+sizeof(A) == sizeof(e)		$\C{// in \CC}$
+/* and sizeof(int) is not necessary equal to sizeof(e) */
+\end{cfa}
+\item[Rationale:] In \CC, an enumeration is a distinct type.
+\item[Effect on original feature:] Change to semantics of well-defined feature.
+\item[Difficulty of converting:] Semantic transformation.
+\item[How widely used:] Seldom. The only time this affects existing C code is when the size of an enumerator is
+taken. Taking the size of an enumerator is not a common C coding practice.
+\end{description}
+\end{comment}
Index: doc/theses/jiada_liang_MMath/background.tex
===================================================================
--- doc/theses/jiada_liang_MMath/background.tex	(revision 92a0ee810313b2b928368cc598624cc69027a7de)
+++ doc/theses/jiada_liang_MMath/background.tex	(revision b0069a30901fd809ec219ff7ac4592aff6c44ac1)
@@ -28,5 +28,5 @@
 
 
-\subsection{C \lstinline{const}}
+\subsection{C \texorpdfstring{\lstinline{const}}{const}}
 \label{s:Cconst}
 
@@ -233,5 +233,5 @@
 
 
-\section{\CFA}
+\section{\texorpdfstring{\CFA}{Cforall}}
 
 \CFA in \emph{not} an object-oriented programming-language, \ie functions cannot be nested in aggregate types, and hence, there is no \newterm{receiver} notation for calling functions, \eg @obj.method(...)@, where the first argument proceeds the call and becomes an  implicit first (\lstinline[language=C++]{this}) parameter.
Index: doc/theses/jiada_liang_MMath/benchmarks.tex
===================================================================
--- doc/theses/jiada_liang_MMath/benchmarks.tex	(revision 92a0ee810313b2b928368cc598624cc69027a7de)
+++ 	(revision )
@@ -1,2 +1,0 @@
-\chapter{Benchmarks}
-\label{s:Benchmarks}
Index: doc/theses/jiada_liang_MMath/conclusion.tex
===================================================================
--- doc/theses/jiada_liang_MMath/conclusion.tex	(revision 92a0ee810313b2b928368cc598624cc69027a7de)
+++ doc/theses/jiada_liang_MMath/conclusion.tex	(revision b0069a30901fd809ec219ff7ac4592aff6c44ac1)
@@ -2,24 +2,42 @@
 \label{c:conclusion}
 
-The goal of this thesis is to adapt enumeration in \CFA to be aligned with the analogous features in 
-other languages while being backward-compatiable to C. 
-The presented features are based off on tools and techniques that widely used in 
-other languages but they were adapted to better fix \CFA's feature set. Additionally, the thesis provides 
-an improvement on safety and productivity of C enumeration, including enumerator overloading, 
-name scoping and type checking.
+The goal of this work is to extend the simple and unsafe enumeration type in the C programming-language into a complex and safe enumeration type in the \CFA programming-language, while maintaining backwards compatibility with C.
+Within this goal, the new \CFA enumeration should align with the analogous enumeration features in other languages to match modern programming expectations.
+Hence, the \CFA enumeration features are burrowed from a number of programming languages, but engineered to work and play with \CFA's type system and feature set.
 
-To further explores the potential of enumerated types, this thesis presents a new \CFA enumeration 
-that is independent on C enumeration. The \CFA enumeration aims to solve the data harmonization problem 
-and have natural support to \CFA generic type, along with some new features that fit with \CFA's
-programming pattern, such as enumerator conctrol structures.
+Additional safety is provided by strong type-checking of enumeration initialization and assignment, ensuring an enumeration only contains its enumerators.
+Overloading and scoping of enumerators significantly reduces the naming problem, providing a better software-engineering environment, with fewer name clashes and the ability to disambiguate those that cannot be implicitly resolved.
+Typed enumerations solve the data-harmonization problem increasing safety through better software engineering.
+As well, integrating enumerations with existing control structures provides a consistent upgrade for programmers, and a succinct and secure mechanism to enumerate with the new loop-range feature.
+Generalization and reuse are supported by incorporating the new enumeration type using the \CFA trait system.
+Enumeration traits define the meaning of an enumeration, allowing functions to be written that work on any enumeration, such as the reading and printing an enumeration.
+Using advanced duck typing, existing C enumerations can be extended so they work with all of the enumeration features, providing for legacy C code to be moved forward into the modern \CFA programming domain.
+Finally, I expanded the \CFA project's test-suite with multiple enumeration features tests, with respect to implicit conversions, control structures, inheritance, interaction with the polymorphic types, and the features built on top of enumeration traits.
+These tests ensure future \CFA work does not accidently break the new enumeration system.
 
-The \CFA project's test suite has been expanded to test the enumerations with respect to its
-implicit conversions, inheritance, interaction with the polymorphic types, and the features 
-built on top of enumeration traits.
+The conclusion is that the new \CFA enumeration mechanisms achieves the initial goals, providing C programmers with an intuitive enumeration mechanism for handling modern programming requirements.
 
-The enumerated type is an attempt to adapt classic data types into \CFA unique type system. It brings 
-valuable new feature to \CFA in its own right, but also serve as a motivation to adapt other data types 
-in \CFA.
 
-% \section{Future Work}
+\section{Future Work}
 
+There are still corner cases being found in the current \CFA enumeration implementation.
+Fixing some of these corner cases, requires changes to the \CFA resolver or extensions to \CFA, like compile-time constant-expression evaluation.
+When these changes are made, it should be straightforward to update the \CFA enumeration implementation to work with them.
+
+Currently, some aspects of the enumeration trait system require explicitly including file @enum.hfa@, which easily leads to problems.
+It should be possible to have this file included implicitly by updating the \CFA prelude.
+
+C already provides @const@-style aliasing using the \emph{unnamed} enumerator \see{\VRef{s:TypeName}}, even if the name @enum@ is misleading (@const@ would be better).
+Given the existence of this form, it is conceivable to extend it with types other than @int@.
+\begin{cfa}
+enum { Size = 20u, PI = 3.14159L, Jack = L"John" };
+\end{cfa}
+which matches with @const@ aliasing in other programming languages.
+Here, the type of the enumerator is the type of the initialization constant, \eg @typeof( 20u )@ for @Size@ implies @unsigned int@.
+Auto-initialization is restricted to the case where all constants are @int@, matching with C.
+As seen in \VRef{s:EnumeratorTyping}, this feature is just a shorthand for multiple typed-enumeration declarations.
+\begin{cfa}
+enum( unsigned int ) { Size = 20u };
+enum( long double ) { PI = 3.14159L };
+enum( wchar_t * ) { Jack = L"John" };
+\end{cfa}
Index: doc/theses/jiada_liang_MMath/glossary.tex
===================================================================
--- doc/theses/jiada_liang_MMath/glossary.tex	(revision 92a0ee810313b2b928368cc598624cc69027a7de)
+++ 	(revision )
@@ -1,47 +1,0 @@
-% % Main glossary entries -- definitions of relevant terminology
-% \newglossaryentry{computer}
-% {
-% name=computer,
-% description={A programmable machine that receives input data,
-%                stores and manipulates the data, and provides
-%                formatted output}
-% }
-
-% % Nomenclature glossary entries -- New definitions, or unusual terminology
-% \newglossary*{nomenclature}{Nomenclature}
-% \newglossaryentry{dingledorf}
-% {
-% type=nomenclature,
-% name=dingledorf,
-% description={A person of supposed average intelligence who makes incredibly brainless misjudgments}
-% }
-
-% % List of Abbreviations (abbreviations type is built in to the glossaries-extra package)
-% \newabbreviation{aaaaz}{AAAAZ}{American Association of Amateur Astronomers and Zoologists}
-
-% % List of Symbols
-% \newglossary*{symbols}{List of Symbols}
-% \newglossaryentry{rvec}
-% {
-% name={$\mathbf{v}$},
-% sort={label},
-% type=symbols,
-% description={Random vector: a location in n-dimensional Cartesian space, where each dimensional component is determined by a random process}
-% }
-
-% Examples from template above
-
-\newabbreviation{foo}{FOO}{\Newterm{Fred Orders Oysters}}
-\newabbreviation{bar}{BAR}{\Newterm{Boys Are Rushed}}
-
-\newglossaryentry{git}{
-name=git,
-first={\Newterm{git}},
-description={is a system that can count the change in your pocket.}
-}
-
-\newglossaryentry{gulp}{
-name={gulp},
-first={\Newterm{gulp}},
-description={a motion made with the mouth.}
-}
Index: doc/theses/jiada_liang_MMath/performance.tex
===================================================================
--- doc/theses/jiada_liang_MMath/performance.tex	(revision 92a0ee810313b2b928368cc598624cc69027a7de)
+++ 	(revision )
@@ -1,3 +1,0 @@
-\chapter{Performance}
-
-If there are any performance experiments.
Index: doc/theses/jiada_liang_MMath/relatedwork.tex
===================================================================
--- doc/theses/jiada_liang_MMath/relatedwork.tex	(revision 92a0ee810313b2b928368cc598624cc69027a7de)
+++ doc/theses/jiada_liang_MMath/relatedwork.tex	(revision b0069a30901fd809ec219ff7ac4592aff6c44ac1)
@@ -448,5 +448,5 @@
 
 
-\section{C\raisebox{-0.7ex}{\LARGE$^\sharp$}\xspace} % latex bug: cannot use \relsize{2} so use \LARGE
+\section{C\texorpdfstring{\raisebox{-0.7ex}{\LARGE$^\sharp$}\xspace}{Csharp}} % latex bug: cannot use \relsize{2} so use \LARGE
 \label{s:Csharp}
 
Index: doc/theses/jiada_liang_MMath/trait.tex
===================================================================
--- doc/theses/jiada_liang_MMath/trait.tex	(revision 92a0ee810313b2b928368cc598624cc69027a7de)
+++ doc/theses/jiada_liang_MMath/trait.tex	(revision b0069a30901fd809ec219ff7ac4592aff6c44ac1)
@@ -24,5 +24,5 @@
 
 
-\section{Traits \lstinline{CfaEnum} and \lstinline{TypedEnum}}
+\section{Traits \texorpdfstring{\lstinline{CfaEnum}{CfaEnum}} and \texorpdfstring{\lstinline{TypedEnum}}{TypedEnum}}
 
 Traits @CfaEnum@ and @TypedEnum@ define the enumeration attributes: @label@, @posn@, @value@, and @Countof@.
@@ -84,5 +84,5 @@
 
 Other types may work with traits @CfaEnum@ and @TypedEnum@, by supplying appropriate @label@, @posn@, and @value@ functions.
-For example, \VRef[Figure]{f:GeneralizedEnumerationFormatter} extends a (possibly predefined) C enumeration to work with all the \CFA extensions.
+For example, \VRef[Figure]{f:ExtendCEnumeration} extends a (possibly predefined) C enumeration to work with all the \CFA extensions.
 
 \begin{figure}
@@ -100,6 +100,6 @@
 sout | format_enum( Cherry );				$\C{// "Cherry(c)"}$
 \end{cfa}
-\caption{Generalized Enumeration Formatter}
-\label{f:GeneralizedEnumerationFormatter}
+\caption{Extend C Enumeration to \CFA Enumeration}
+\label{f:ExtendCEnumeration}
 \end{figure}