Index: doc/theses/jiada_liang_MMath/background.tex
===================================================================
--- doc/theses/jiada_liang_MMath/background.tex	(revision 9d3a4cc8f1758107f333259e1ea5aabf6a260d5c)
+++ doc/theses/jiada_liang_MMath/background.tex	(revision ab11ab1beb9d10d00e4dab6b43817c7e9271e435)
@@ -89,5 +89,5 @@
 Here, the aliased constants are: 20, 10, 20, 21, and -7.
 Direct initialization is by a compile-time expression generating a constant value.
-Indirect initialization (without initializer, @Max10Plus1@) is called \newterm{auto-initialization}, where enumerators are assigned values from left to right, starting at zero or the next explicitly initialized constant, incrementing by @1@.
+Indirect initialization (without an initializer, @Max10Plus1@) is called \newterm{auto-initialization}, where enumerators are assigned values from left to right, starting at zero or the next explicitly initialized constant, incrementing by @1@.
 Because multiple independent enumerators can be combined, enumerators with the same values can occur.
 The enumerators are rvalues, so assignment is disallowed.
@@ -112,5 +112,5 @@
 enum @Week@ { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun };
 \end{clang}
-and adopts the same semantics with respect to direct and auto intialization.
+and adopts the same semantics as direct and auto initialization.
 For example, @Mon@ to @Wed@ are implicitly assigned with constants @0@--@2@, @Thu@ is explicitly set to constant @10@, and @Fri@ to @Sun@ are implicitly assigned with constants @11@--@13@.
 As well, initialization may occur in any order.
@@ -123,5 +123,5 @@
 Note, the comma in the enumerator list can be a terminator or a separator, allowing the list to end with a dangling comma.\footnote{
 A terminating comma appears in other C syntax, \eg the initializer list.}
-This feature allow enumerator lines to be interchanged without moving a comma.
+This feature allows enumerator lines to be interchanged without moving a comma.
 Named enumerators are also unscoped.
 
@@ -136,5 +136,5 @@
 A ``plain'' @int@ object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range @INT_MIN@ to @INT_MAX@ as defined in the header @<limits.h>@).~\cite[\S~6.2.5(5)]{C11}
 \end{quote}
-However, @int@ means a 4 bytes on both 32/64-bit architectures, which does not seem like the ``natural'' size for a 64-bit architecture.
+However, @int@ means 4 bytes on both 32/64-bit architectures, which does not seem like the ``natural'' size for a 64-bit architecture.
 Whereas, @long int@ means 4 bytes on a 32-bit and 8 bytes on 64-bit architectures, and @long long int@ means 8 bytes on both 32/64-bit architectures, where 64-bit operations are simulated on 32-bit architectures.
 \VRef[Figure]{f:gccEnumerationStorageSize} shows both @gcc@ and @clang@ partially ignore this specification and type the integral size of an enumerator based its initialization.
@@ -204,5 +204,5 @@
 \end{cfa}
 Here, serendipitously the auto-incrementing counts the number of enumerators and puts the total into the last enumerator @N@.
-This @N@ is often used as the dimension for an array assocated with the enumeration.
+This @N@ is often used as the dimension for an array associated with the enumeration.
 \begin{cfa}
 E array[@N@];
@@ -235,5 +235,5 @@
 \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.
+\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.
 The following sections provide short descriptions of \CFA features needed further in the thesis.
 Other \CFA features are presented in-situ with short explanations, or no explanation because the feature is obvious to C programmers.
@@ -263,5 +263,5 @@
 s1 = @?+?@( s1, s2 );	$\C{// direct call}\CRT$
 \end{cfa}
-The type system examines each call size and selects the best matching overloaded function based on the number and types of the arguments.
+The type system examines each call size and selects the best matching overloaded function based on the number and types of arguments.
 If there are mixed-mode operands, @2 + 3.5@, the type system, like in C/\CC, attempts (safe) conversions, converting the argument type(s) to the parameter type(s).
 
@@ -308,6 +308,6 @@
 \subsection{Constructor and Destructor}
 
-While \CFA in not object oriented, it adopts many language features commonly used in object-oriented languages;
-these features are independent from object-oriented programming.
+While \CFA is not object-oriented, it adopts many language features commonly used in object-oriented languages;
+these features are independent of object-oriented programming.
 
 All objects in \CFA are initialized by @constructors@ \emph{after} allocation and de-initialized \emph{before} deallocation.
@@ -378,5 +378,5 @@
 At the call size, the type parameter @T@ is bounded to @int@ from the argument @42@.
 
-For polymorphic functions to be useful, the @forall@ clause needs \newterm{type assertion}s that restricts the polymorphic types it accepts.
+For polymorphic functions to be useful, the @forall@ clause needs \newterm{type assertion}s that restrict the polymorphic types it accepts.
 \begin{cfa}
 forall( T @| { void foo( T ); }@ ) void bar( T t ) { @foo( t );@ }
@@ -392,5 +392,5 @@
 
 A @forall@ clause can assert many restrictions on multiple types.
-A common practice is to refactor the assertions into a named \newterm{trait}, similar to other lnaguages, like Go and Rust.
+A common practice is to refactor the assertions into a named \newterm{trait}, similar to other languages, like Go and Rust.
 \begin{cfa}
 forall(T) trait @Bird@ {
@@ -416,5 +416,5 @@
 When multiple best matches exist, the resolution is ambiguous.
 
-The \CFA resolver attempts to identity a best candidate based on: first, the number of parameters and types, and second, when no exact match exists, the fewest implicit conversions and polymorphic variables.
+The \CFA resolver attempts to identify the best candidate based on: first, the number of parameters and types, and second, when no exact match exists, the fewest implicit conversions and polymorphic variables.
 Finding an exact match is not discussed here, because the mechanism is fairly straightforward, even when the search space is large;
 only finding a non-exact match is discussed in detail.
@@ -425,8 +425,8 @@
 
 Most programming languages perform some implicit conversions among basic types to facilitate mixed-mode arithmetic;
-otherwise, the program becomes littered with many explicit casts, which does not match with programmer expectation.
+otherwise, the program becomes littered with many explicit casts, which does not match with programmer's expectations.
 C is an aggressive language as it provides conversions among almost all of the basic types, even when the conversion is potentially unsafe or not meaningful, \ie @float@ to @bool@.
 C defines the resolution pattern as ``usual arithmetic conversion''~\cite[\S~6.3.1.8]{C11}, in which C looks for a \newterm{common type} between operands, and converts one or both operands to the common type.
-Loosely defined, a common type is a the smallest type in terms of size of representation that both operands can be converted into without losing their precision, called a \newterm{widening} or \newterm{safe conversion}.
+Loosely defined, a common type is the smallest type in terms of the size of representation that both operands can be converted into without losing their precision, called a \newterm{widening} or \newterm{safe conversion}.
 
 \CFA generalizes ``usual arithmetic conversion'' to \newterm{conversion cost}.
@@ -441,13 +441,13 @@
 \end{enumerate}
 Sum of degree is a method to quantify C's integer and floating-point rank.
-Every pair of widening conversion types is assigned a \newterm{distance}, and distance between the two same type is 0.
-For example, the distance from @char@ to @int@ is 2, distance from @int@ to @long@ is 1, and distance from @int@ to @long long int@ is 2.
+Every pair of widening conversion types is assigned a \newterm{distance}, and the distance between the two same types is 0.
+For example, the distance from @char@ to @int@ is 2, the distance from @int@ to @long@ is 1, and the distance from @int@ to @long long int@ is 2.
 This distance does not mirror C's rank system.
 For example, the rank of @char@ and @signed char@ are the same in C, but the distance from @char@ to @signed char@ is assigned 1.
-@safe@ cost is summing all pairs of argument to parameter safe conversion distances.
+@safe@ cost is summing all pairs of arguments to parameter safe conversion distances.
 Among the three costs in Bilson's model, @unsafe@ is the most significant cost and @safe@ is the least significant, with an implication that \CFA always choose a candidate with the lowest @unsafe@, if possible.
 
 For example, assume the overloaded function @foo@ is called with two @int@ parameter.
-The cost for every overloaded @foo@ has been list along:
+The cost for every overloaded @foo@ has been listed along:
 \begin{cfa}
 void foo( char, char );				$\C[2.5in]{// (1) (2, 0, 0)}$
@@ -462,5 +462,5 @@
 foo( i, j );						$\C{// convert j to long and call (8)}\CRT$
 \end{cfa}
-The overloaded instances are ordered from the highest to the lowest cost, and \CFA select the last candidate (8).
+The overloaded instances are ordered from the highest to the lowest cost, and \CFA selects the last candidate (8).
 
 In the next iteration of \CFA, Schluntz and Aaron~\cite{Moss18} expanded conversion cost to a 7-tuple with 4 additional categories, @(unsafe, poly, safe, sign, vars, specialization, reference)@, with the following interpretations:
@@ -469,12 +469,12 @@
 \item \textit{Poly}
 \item \textit{Safe}
-\item \textit{Sign} is the number of sign/unsign variable conversion.
-\item \textit{Vars} is the number of polymorphics type variable.
-\item \textit{Specialization} is negative value of the number of type assertion.
+\item \textit{Sign} is the number of sign/unsign variable conversions.
+\item \textit{Vars} is the number of polymorphic type variables.
+\item \textit{Specialization} is the negative value of the number of type assertions.
 \item \textit{Reference} is number of reference-to-rvalue conversion.
 \end{itemize}
 The extended conversion-cost model looks for candidates that are more specific and less generic.
 @vars@ disambiguates @forall( T, V ) foo( T, V )@ and @forall( T ) void foo( T, T )@, where the extra type parameter @V@ makes is more generic.
-A more generic type means less constraints on its parameter types.
+A more generic type means fewer constraints on its parameter types.
 \CFA favours candidates with more restrictions on polymorphism, so @forall( T ) void foo( T, T )@ has lower cost.
 @specialization@ is an arbitrary count-down value starting at zero.
@@ -483,9 +483,9 @@
 
 \CFA defines two special cost values: @zero@ and @infinite@.
-A conversion cost is @zero@ when argument and parameter has an exact match, and a conversion cost is @infinite@ when there is no defined conversion between two types.
+A conversion cost is @zero@ when the argument and parameter have an exact match, and a conversion cost is @infinite@ when there is no defined conversion between two types.
 For example, the conversion cost from @int@ to a @struct S@ is @infinite@.
 
 In \CFA, the meaning of a C-style cast is determined by its @Cast Cost@.
-For most cast-expression resolution, a cast cost is equal to a conversion cost.
+For most cast-expression resolutions, a cast cost is equal to a conversion cost.
 Cast cost exists as an independent matrix for conversion that cannot happen implicitly, while being possible with an explicit cast.
-These conversions are often defined to have infinite conversion cost and non-infinite cast cost.
+These conversions are often defined to have a infinite conversion cost and a non-infinite cast cost.
