Index: doc/theses/jiada_liang_MMath/CFAenum.tex
===================================================================
--- doc/theses/jiada_liang_MMath/CFAenum.tex	(revision dd78dbccf03bf11d25fbf309c86c57e11151a3bb)
+++ doc/theses/jiada_liang_MMath/CFAenum.tex	(revision fcf34935cc303d67bf0219d576c66ddf0a1c4f97)
@@ -114,6 +114,6 @@
 \subsection{Value Conversion}
 C has an implicit type conversion from an enumerator to its base type @int@.
-Correspondingly, \CFA has an implicit conversion from a typed enumerator to its base type. The feature that allows Typed enumeration 
-seemlyless used 
+Correspondingly, \CFA has an implicit conversion from a typed enumerator to its base type, allowing typed enumeration to be seemlyless used as 
+a value of its base type. 
 \begin{cfa}
 char currency = Dollar;
@@ -122,10 +122,19 @@
 \end{cfa}
 
-During the resolution of expression e with \CFA enumeration type, \CFA adds @value(e)@ as an additional candidate with an extra \newterm{value} cost.
-For expression @char currency = Dollar@, the is no defined conversion from Dollar (\CFA enumeration) type to basic type and the conversion cost is @infinite@, 
-thus the only valid candidate is @value(Dollar)@.
-
-@Value@ is a new category in \CFA's conversion cost model. It is defined to be a more significant factor than a @unsafe@ but weight less than @poly@.
-The resultin g conversion cost is a 8-tuple:
+% During the resolution of expression e with \CFA enumeration type, \CFA adds @value(e)@ as an additional candidate with an extra \newterm{value} cost.
+% For expression @char currency = Dollar@, the is no defined conversion from Dollar (\CFA enumeration) type to basic type and the conversion cost is @infinite@, 
+% thus the only valid candidate is @value(Dollar)@.
+The implicit conversion induces a \newterm{value cost}, which is a new category in \CFA's conversion cost model to disambiguate function overloading over for both \CFA enumeration and its base type.
+\begin{cfa}
+void baz( char ch );		$\C{// (1)}$
+void baz( Currency cu );	$\C{// (2)}$
+
+baz( Cent );
+\end{cfa}
+While both baz are applicable to \CFA enumeration, using Cent as a char in @candiate (1)@ comes with a @value@ cost, 
+while @candidate (2)@ has @zero@ cost. \CFA always choose a overloaded candidate implemented for a \CFA enumeration itself over a candidate applies on a base type.
+
+Value cost is defined to be a more significant factor than an @unsafe@ but weight less than @poly@.
+With @value@ being an additional category, the current \CFA conversion cost is a 8-tuple:
 @@(unsafe, value, poly, safe, sign, vars, specialization, reference)@@.
 
@@ -137,6 +146,6 @@
 };
 
-Month a = Februrary;	// (1), with cost (0, 1, 0, 0, 0, 0, 0, 0)
-double a = 5.5;			// (2), with cost (1, 0, 0, 0, 0, 0, 0, 0)
+Month a = Februrary;	$\C{// (1), with cost (0, 1, 0, 0, 0, 0, 0, 0)}$
+double a = 5.5;			$\C{// (2), with cost (1, 0, 0, 0, 0, 0, 0, 0)}$
 
 bar(a);
@@ -148,5 +157,5 @@
 forall(T | @CfaEnum(T)@) void bar(T);
 
-bar(a);					// (3), with cost (0, 0, 1, 0, 0, 0, 0, 0)
+bar(a);					$\C{// (3), with cost (0, 0, 1, 0, 0, 0, 0, 0)}$ 
 \end{cfa}
 % @Value@ is designed to be less significant than @poly@ to allow function being generic over \CFA enumeration (see ~\ref{c:trait}). 
@@ -192,5 +201,9 @@
 \section{Enumeration Inheritance}
 
-\CFA Plan-9 inheritance may be used with enumerations, where Plan-9 inheritance is containment inheritance with implicit unscoping (like a nested unnamed @struct@/@union@ in C).
+\CFA Plan-9 inheritance may be used with \CFA enumerations, where Plan-9 inheritance is containment inheritance with implicit unscoping (like a nested unnamed @struct@/@union@ in C).
+Inheritance can be nested, and a \CFA enumeration can inline enumerators from more than one \CFA enumeration, forming a tree-like structure.
+Howver, the uniqueness of enumeration label applies to enumerators from supertypes, meaning an enumeration cannot name enumerator with the same label as its subtype's members, or inherits 
+from multiple enumeration that has overlapping enumerator label. As a consequence, a new type cannot inherits both an enumeration and its supertype, or inherit two enumerations with a 
+common supertype (the diamond problem), since such would unavoidably introduce duplicate enumerator labels. 
 
 \begin{cfa}
@@ -200,6 +213,9 @@
 \end{cfa}
 
-Enumeration @Name2@ inherits all the enumerators and their values from enumeration @Names@ by containment, and a @Names@ enumeration is a @subtype@ of enumeration @Name2@.
-Note, that enumerators must be unique in inheritance but enumerator values may be repeated.
+% Enumeration @Name2@ inherits all the enumerators and their values from enumeration @Names@ by containment, and a @Names@ enumeration is a @subtype@ of enumeration @Name2@.
+% Note, that enumerators must be unique in inheritance but enumerator values may be repeated.
+
+@Names2@ is defined with five enumerators, three of which are from @Name@ through containment, and two are self-declared.
+@Names3@ inherits all five members from @Names2@ and declare two additional enumerators.
 
 % The enumeration type for the inheriting type must be the same as the inherited type;
@@ -211,6 +227,12 @@
 \end{cfa}
 
-Inlined from \CFA enumeration @O@, new enumeration @N@ copies all enumerators from @O@, including those @O@ obtains through inheritance. Enumerators inherited from @O@
-keeps same @label@ and @value@, but @position@ may shift to the right if other enumerators or inline enumeration declared in prior of @inline A@.
+The enumeration type for the inheriting type must be the same as the inherited type. 
+When an enumeration inherits enumerators from another enumeration, it copies the enumerators' @value@ and @label@, even if the @value@ was auto initialized. However, the @position@ as the underlying 
+representation will be the order of the enumerator in new enumeration.
+% new enumeration @N@ copies all enumerators from @O@, including those @O@ obtains through inheritance. Enumerators inherited from @O@
+% keeps same @label@ and @value@, but @position@ may shift to the right if other enumerators or inline enumeration declared in prior of @inline A@.
+% hence the enumeration type may be omitted for the inheriting enumeration and it is inferred from the inherited enumeration, as for @Name3@.
+% When inheriting from integral types, automatic numbering may be used, so the inheritance placement left to right is important.
+
 \begin{cfa}
 enum() Phynchocephalia { Tuatara };
@@ -220,5 +242,5 @@
 Snake, for example, has the position 0 in Squamata, but 1 in Lepidosauromorpha as Tuatara inherited from Phynchocephalia is position 0 in Lepidosauromorpha.
 
-A subtype enumeration can be casted, or implicitly converted into its supertype, with a safe cost.
+A subtype enumeration can be casted, or implicitly converted into its supertype, with a @safe@ cost.
 \begin{cfa}
 enum Squamata squamata_lizard = Lizard;
Index: doc/theses/jiada_liang_MMath/background.tex
===================================================================
--- doc/theses/jiada_liang_MMath/background.tex	(revision dd78dbccf03bf11d25fbf309c86c57e11151a3bb)
+++ doc/theses/jiada_liang_MMath/background.tex	(revision fcf34935cc303d67bf0219d576c66ddf0a1c4f97)
@@ -157,5 +157,5 @@
 \label{s:Usage}
 
-C proves an implicit \emph{bidirectional} conversion between an enumeration and its integral type.
+C proves an implicit \emph{bidirectional} conversion between an enumeration and its integral type, and between two different enumeration.
 \begin{clang}
 enum Week week = Mon;				$\C{// week == 0}$
@@ -163,4 +163,7 @@
 int i = Sun;						$\C{// implicit conversion to int, i == 13}$
 @week = 10000;@						$\C{// UNDEFINED! implicit conversion to Week}$
+
+enum Season {Spring, Summer, Fall, Winter };
+@week = Winter;@					$\C{// UNDEFINED! implicit conversion to Week}$
 \end{clang}
 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.
Index: doc/theses/jiada_liang_MMath/conclusion.tex
===================================================================
--- doc/theses/jiada_liang_MMath/conclusion.tex	(revision dd78dbccf03bf11d25fbf309c86c57e11151a3bb)
+++ doc/theses/jiada_liang_MMath/conclusion.tex	(revision fcf34935cc303d67bf0219d576c66ddf0a1c4f97)
@@ -1,5 +1,25 @@
 \chapter{Conclusion}
+\label{c:conclusion}
 
-The goal of this thesis is to ...
+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.
 
-\section{Future Work}
+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.
+
+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 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}
+