Index: doc/theses/jiada_liang_MMath/conclusion.tex
===================================================================
--- doc/theses/jiada_liang_MMath/conclusion.tex	(revision fd0a9bf98db77f1225239c787cba42c176593bc5)
+++ doc/theses/jiada_liang_MMath/conclusion.tex	(revision 7cb14c96f1e1ef1941f5a844729a31bfa0a9929f)
@@ -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}