Changes in / [7db4fcd4:cc077f4]

Location:

doc/theses/jiada_liang_MMath

Files:

• CEnum.tex (modified) (4 diffs)
• CFAenum.tex (modified) (15 diffs)
• background.tex (modified) (6 diffs)
• intro.tex (modified) (1 diff)

doc/theses/jiada_liang_MMath/CEnum.tex

@@ -1 +1 @@
 \chapter{C Enumeration in \CFA}
 
-\CFA supports legacy C enumeration using the same syntax for backwards compatibility. 
+\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 C Enums.
+The following sections detail all of my new contributions to enumerations in C.
 
 
@@ -56 +56 @@
 rgb = @RGB.@Blue;
 \end{cfa}
-% feature unimplemented
+% 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}
@@ -65 +65 @@
 \end{cfa}
 As in Section~\ref{s:EnumeratorVisibility}, 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.
 
 
@@ -76 +85 @@
 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 }$ 
+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 
+enum Bird bird = @(Bird)@Shark
 \end{cfa}
 

doc/theses/jiada_liang_MMath/CFAenum.tex

@@ -1 +1 @@
 \chapter{\CFA Enumeration}
 
-% \CFA supports C enumeration using the same syntax and semantics for backwards compatibility.
-% \CFA also extends C-Style enumeration by adding a number of new features that bring enumerations inline with other modern programming languages.
-% Any enumeration extensions must be intuitive to C programmers both in syntax and semantics.
-% The following sections detail all of my new contributions to enumerations in \CFA.
-\CFA extends the enumeration declaration by parameterizing with a type (like a generic type).
-
-
-\begin{cfa}[caption={CFA Enum},captionpos=b,label={l:CFAEnum}]
+\CFA extends C-Style enumeration by adding a number of new features that bring enumerations inline with other modern programming languages.
+Any enumeration extensions must be intuitive to C programmers both in syntax and semantics.
+The following sections detail all of my new contributions to enumerations in \CFA.
+
+
+\section{Enumeration Syntax}
+
+\CFA extends the C enumeration declaration \see{\VRef{s:CEnumeration}} by parameterizing with a type (like a generic type), and adding Plan-9 inheritance \see{\VRef{s:EnumerationInheritance}} using an @inline@ to another enumeration type.
+\begin{cfa}[identifierstyle=\linespread{0.9}\it]
 $\it enum$-specifier:
         enum @(type-specifier$\(_{opt}\)$)@ identifier$\(_{opt}\)$ { cfa-enumerator-list }
@@ -15 +16 @@
 cfa-enumerator-list:
         cfa-enumerator
-        cfa-enumerator, cfa-enumerator-list
+        cfa-enumerator-list, cfa-enumerator
 cfa-enumerator:
         enumeration-constant
-        $\it inline$ identifier
-        enumeration-constant = expression
-\end{cfa}
-
-A \newterm{\CFA enumeration}, or \newterm{\CFA enum}, has an optional type declaration in the bracket next to the @enum@ keyword.
-Without optional type declarations, the syntax defines \newterm{opaque enums}.
-Otherwise, \CFA enum with type declaration are \newterm{typed enums}.
-
-\section{Opaque Enum}
+        @inline $\color{red}enum$-type-name@
+        enumeration-constant = constant-expression
+\end{cfa}
+
+
+\section{Enumeration Operations}
+
+\CFA enumerations have access to the three enumerations properties \see{\VRef{s:Terminology}}: label, order (position), and value via three overloaded functions @label@, @posn@, and @value@ \see{\VRef{c:trait} for details}.
+\CFA auto-generates these functions for every \CFA enumeration.
+\begin{cfa}
+enum(int) E { A = 3 } e = A;
+sout | A | @label@( A ) | @posn@( A ) | @value@( A );
+sout | e | @label@( e ) | @posn@( e ) | @value@( e );
+A A 0 3
+A A 0 3
+\end{cfa}
+For output, the default is to print the label.
+An alternate way to get an enumerator's position is to cast it to @int@.
+\begin{cfa}
+sout | A | label( A ) | @(int)A@ | value( A );
+sout | A | label( A ) | @(int)A@ | value( A );
+A A @0@ 3
+A A @0@ 3
+\end{cfa}
+Finally, there is an additional enumeration routine @countof@ (like @sizeof@, @typeof@) that returns the number of enumerators in an enumeration.
+\begin{cfa}
+enum(int) E { A, B, C, D };
+countof( E );  // 4
+\end{cfa}
+This auto-generated function replaces the C idiom for automatically computing the number of enumerators \see{\VRef{s:Usage}}.
+\begin{cfa}
+enum E { A, B, C, D, @N@ };  // N == 4
+\end{cfa}
+
+The underlying representation of \CFA enumeration object is its position, saved as an integral type.
+Therefore, the size of a \CFA enumeration is consistent with a C enumeration.
+Attribute function @posn@ performs type substitution on an expression from \CFA type to integral type.
+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}
 \label{s:OpaqueEnum}
-Opaque enum is a special CFA enumeration type, where the internal representation is chosen by the compiler and hidden from users.
-Compared C enum, opaque enums are more restrictive in terms of typing, and cannot be implicitly converted to integers.
-Enumerators of opaque enum cannot have initializer. Declaring initializer in the body of opaque enum results in a compile time error.
-\begin{cfa}
-enum@()@ Planets { MERCURY, VENUS, EARTH, MARS, JUPITER, SATURN, URANUS, NEPTUNE };
-
-Planet p = URANUS;
-int i = VENUS; @// Error, VENUS cannot be converted into an integral type
-\end{cfa}
-% Each opaque enum has two @attributes@: @position@ and @label@. \CFA auto-generates @attribute functions@ @posn()@ and @label()@ for every \CFA enum to returns the respective attributes.
-Opaque enumerations have two defining properties: @label@ (name) and @order@ (position), exposed to users by predefined @attribute functions@ , with the following signatures:
-\begin{cfa}
-forall( E ) {
-        unsigned posn(E e);
-        const char * s label(E e);
-};
-\end{cfa}
-With polymorphic type parameter E being substituted by enumeration types such as @Planet@.
-
-\begin{cfa}
-unsigned i = posn(VENUS); // 1
-char * s = label(MARS); // "MARS"
-\end{cfa}
-
-\subsection{Representation}
-The underlying representation of \CFA enumeration object is its order, saved as an integral type. Therefore, the size of a \CFA enumeration is consistent with C enumeration.
-Attribute function @posn@ performs type substitution on an expression from \CFA type to integral type. 
-Names of enumerators are stored in a global data structure, with @label@ maps \CFA enumeration object to corresponding data.
-
-\section{Typed Enum}
+
+When an enumeration type is empty is it an \newterm{opaque} enumeration.
+\begin{cfa}
+enum@()@ Mode { O_RDONLY, O_WRONLY, O_CREAT, O_TRUNC, O_APPEND };
+\end{cfa}
+Here, the internal representation is chosen by the compiler and hidden, so the enumerators cannot be initialized.
+Compared to the C enum, opaque enums are more restrictive in terms of typing and cannot be implicitly converted to integers.
+\begin{cfa}
+Mode mode = O_RDONLY;
+int www @=@ mode;                                               $\C{// disallowed}$
+\end{cfa}
+Opaque enumerations have only two attribute properties @label@ and @posn@.
+\begin{cfa}
+char * s = label( O_TRUNC );                    $\C{// "O\_TRUNC"}$
+int open = posn( O_WRONLY );                    $\C{// 1}$
+\end{cfa}
+The equality and relational operations are available.
+\begin{cfa}
+if ( mode @==@ O_CREAT ) ...
+bool b = mode @<@ O_APPEND;
+\end{cfa}
+
+
+\section{Typed Enumeration}
 \label{s:EnumeratorTyping}
 
-\CFA extends the enumeration declaration by parameterizing with a type (like a generic type), allowing enumerators to be assigned any values from the declared type.
+When an enumeration type is specified, all enumerators have that type and can be initialized with constants of that type or compile-time convertable to that type.
 Figure~\ref{f:EumeratorTyping} shows a series of examples illustrating that all \CFA types can be use with an enumeration and each type's values used to set the enumerator constants.
-Note, the synonyms @Liz@ and @Beth@ in the last declaration.
+Note, the use of the synonyms @Liz@ and @Beth@ in the last declaration.
 Because enumerators are constants, the enumeration type is implicitly @const@, so all the enumerator types in Figure~\ref{f:EumeratorTyping} are logically rewritten with @const@.
 
@@ -86 +113 @@
 // aggregate
         struct Person { char * name; int age, height; };
-@***@enum( @Person@ ) friends { @Liz@ = { "ELIZABETH", 22, 170 }, @Beth@ = Liz,
+        enum( @Person@ ) friends { @Liz@ = { "ELIZABETH", 22, 170 }, @Beth@ = Liz,
                                                                         Jon = { "JONATHAN", 35, 190 } };
 \end{cfa}
+% synonym feature unimplemented
 \caption{Enumerator Typing}
 \label{f:EumeratorTyping}
@@ -104 +132 @@
 Note, the enumeration type can be a structure (see @Person@ in Figure~\ref{f:EumeratorTyping}), so it is possible to have the equivalent of multiple arrays of companion data using an array of structures.
 
-While the enumeration type can be any C aggregate, the aggregate's \CFA constructors are not used to evaluate an enumerator's value.
+While the enumeration type can be any C aggregate, the aggregate's \CFA constructors are \emph{not} used to evaluate an enumerator's value.
 \CFA enumeration constants are compile-time values (static);
 calling constructors happens at runtime (dynamic).
 
-@value@ is an @attribute@ that defined for typed enum along with position and label. @values@ of a typed enum are stored in a global array of declared typed, initialized with 
-value of enumerator initializers. @value()@ functions maps an enum to an elements of the array.
-
-
-\subsection{Value Conversion}
+
+\section{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, allowing typed enumeration to be seemlyless used as 
-a value of its base type. 
-\begin{cfa}
-char currency = Dollar;
-void foo( char * );
-foo( Fred );
-\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)@.
-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.
+Correspondingly, \CFA has an implicit conversion from a typed enumerator to its base type, allowing typed enumeration to be seamlessly used as the value of its base type
+For example, using type @Currency@ in \VRef[Figure]{f:EumeratorTyping}:
+\begin{cfa}
+char currency = Dollar;         $\C{// implicit conversion to base type}$
+void foo( char );
+foo( Dollar );                          $\C{// implicit conversion to base type}$
+\end{cfa}
+The implicit conversion induces a \newterm{value cost}, which is a new category (8 tuple) in \CFA's conversion cost model \see{\VRef{s:ConversionCost}} to disambiguate function overloading over a \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)@@.
-
-\begin{cfa}
-void bar(int);
-enum(int) Month !{ 
-        January=31, February=29, March=31, April=30, May=31, June-30,
-        July=31, August=31, September=30, October=31, November=30, December=31
-};
-
-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);
-\end{cfa}
-In the previous example, candidate (1) has an value cost to parameter type int, with is lower than (2) as an unsafe conversion from double to int.
-\CFA chooses value cost over unsafe cost and therefore @a@ of @bar(a)@ is resolved as an @Month@.
-
-\begin{cfa}
-forall(T | @CfaEnum(T)@) void bar(T);
-
-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}). 
-Being generic over @CfaEnum@ traits (a pre-defined interface for \CFA enums) is a practice in \CFA to implement functions over \CFA enumerations, as will see in chapter~\ref{c:trait}.
-@Value@ is a being a more significant cost than @poly@ implies if a overloaeded function defined for @CfaEnum@ (and other generic type), \CFA always 
-try to resolve it as a @CfaEnum@, rather to insert a @value@ conversion.
-
-\subsection{Explicit Conversion}
-Explicit conversion is allowed on \CFA enumeration to an integral type, in which case \CFA converts \CFA enumeration into its underlying representation,
-which is its @position@.
-
-\section{Auto Initialization} 
-
-C auto-initialization works for the integral type @int@ with constant expressions.
-\begin{cfa}
-enum Alphabet ! {
-        A = 'A', B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z,
-        a = 'a', b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z
-};
-\end{cfa}
-The complexity of the constant expression depends on the level of runtime computation the compiler implements, \eg \CC \lstinline[language={[GNU]C++}]{constexpr} provides complex compile-time computation across multiple types, which blurs the compilation/runtime boundary.
-
-% The notion of auto-initialization is generalized in \CFA enumertation E with base type T in the following way:
-When an enumerator @e@ does not have a initializer, if @e@ has enumeration type @E@ with base type @T@, \CFA auto-initialize @e@ with the following scheme:
+baz( Dollar );
+\end{cfa}
+While both @baz@ functions are applicable to the enumerator @Dollar@, @candidate (1)@ comes with a @value@ cost for the conversion to the enumeration's base type, while @candidate (2)@ has @zero@ cost.
+Hence, \CFA chooses the exact match.
+Value cost is defined to be a more significant factor than an @unsafe@ but less than the other conversion costs: @(unsafe,@ {\color{red}@value@}@, poly, safe, sign, vars, specialization,@ @reference)@.
+\begin{cfa}
+void bar( @int@ );
+Math x = PI;                            $\C{// (1)}$
+double x = 5.5;                         $\C{// (2)}$
+bar( x );                                       $\C{// costs (1, 0, 0, 0, 0, 0, 0, 0) or (0, 1, 0, 0, 0, 0, 0, 0)}$
+\end{cfa}
+Here, candidate (1) has a value conversion cost to convert to the base type, while candidate (2) has an unsafe conversion from @double@ to @int@.
+Hence, @bar( x )@ resolves @x@ as type @Math@.
+
+% \begin{cfa}
+% forall(T | @CfaEnum(T)@) void bar(T);
+% 
+% 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}).
+% Being generic over @CfaEnum@ traits (a pre-defined interface for \CFA enums) is a practice in \CFA to implement functions over \CFA enumerations, as will see in chapter~\ref{c:trait}.
+% @Value@ is a being a more significant cost than @poly@ implies if a overloaeded function defined for @CfaEnum@ (and other generic type), \CFA always try to resolve it as a @CfaEnum@, rather to insert a @value@ conversion.
+
+
+\section{Auto Initialization}
+
+A partially implemented feature is auto-initialization, which works for the C integral type with constant expressions.
+\begin{cfa}
+enum Week { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun }; // 0-2, 10-13
+\end{cfa}
+The complexity of the constant expression depends on the level of computation the compiler implements, \eg \CC \lstinline[language={[GNU]C++}]{constexpr} provides complex compile-time computation across multiple types, which blurs the compilation/runtime boundary.
+
+If \CFA had powerful compilation expression evaluation, auto initialization would be implemented as follows.
+\begin{cfa}
+enum E(T) { A, B, C };
+\end{cfa}
 \begin{enumerate}
-% \item Enumerator e is the first enumerator of \CFA enumeration E with base type T. If e declares no no initializer, e is auto-initialized by the $zero\_t$ constructor of T.
-\item if e is first enumerator, e is initialized with T's @zero_t@.
-\item otherwise, if d is the enumerator defined just before e, with d has has been initialized with expression @l@ (@l@ can also be an auto-generated), e is initialized with @l++@. 
-% \CFA reports a compile time error if T has no $zero\_t$ constructor.
-% Enumerator e is an enumerator of base-type T enumeration E that position i, where $i \neq 0$. And d is the enumerator with position @i-1@, e is auto-initialized with 
-% the result of @value(d)++@. If operator @?++@ is not defined for type T, \CFA reports a compile time error.
-
-% Unfortunately, auto-initialization is not implemented because \CFA is only a transpiler, relying on generated C code to perform the detail work.
-% C does not have the equivalent of \CC \lstinline[language={[GNU]C++}]{constexpr}, and it is currently beyond the scope of the \CFA project to implement a complex runtime interpreter in the transpiler.
-% Nevertheless, the necessary language concepts exist to support this feature.
+\item the first enumerator, @A@, is initialized with @T@'s @zero_t@.
+\item otherwise, the next enumerator is initialized with the previous enumerator's value using operator @?++@, where @?++( T )@ can be overloaded for any type @T@.
 \end{enumerate}
-while @?++( T )@ can be explicitly overloaded or implicitly overloaded with properly defined @one_t@ and @?+?(T, T)@.
-
-Unfortunately, auto-initialization with only constant expression is not enforced because \CFA is only a transpiler, relying on generated C code to perform the detail work.
-C does not have the equivalent of \CC \lstinline[language={[GNU]C++}]{constexpr}, and it is currently beyond the scope of the \CFA project to implement a complex runtime interpreter in the transpiler.
+
+Unfortunately, constant expressions in C are not powerful and \CFA is only a transpiler, relying on generated C code to perform the detail work.
+It is currently beyond the scope of the \CFA project to implement a complex runtime interpreter in the transpiler to evaluate complex expressions across multiple builtin and user-defined type. 
 Nevertheless, the necessary language concepts exist to support this feature.
 
+
 \section{Enumeration Inheritance}
+\label{s:EnumerationInheritance}
 
 \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).
-Containment is norminative: an enumeration inherits all enumerators from another enumeration by declaring an @inline statement@ in its enumerator lists.
-\begin{cfa}
-enum( char * ) Names { /* as above */ };
+Containment is nominative: an enumeration inherits all enumerators from another enumeration by declaring an @inline statement@ in its enumerator lists.
+\begin{cfa}
+enum( char * ) Names { /* $\see{\VRef[Figure]{s:EnumerationInheritance}}$ */ };
 enum( char * ) Names2 { @inline Names@, Jack = "JACK", Jill = "JILL" };
 enum( char * ) Names3 { @inline Names2@, Sue = "SUE", Tom = "TOM" };
 \end{cfa}
 In the preceding example, @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.
-
-Enumeration inheritance forms a subset relationship. Specifically, the inheritance relationship for the example above is:
+@Names3@ inherits all five members from @Names2@ and declares two additional enumerators.
+Hence, enumeration inheritance forms a subset relationship.
+Specifically, the inheritance relationship for the example above is:
 \begin{cfa}
 Names $\(\subset\)$ Names2 $\(\subset\)$ Names3 $\C{// enum type of Names}$
@@ -217 +216 @@
 
 Inheritance can be nested, and a \CFA enumeration can inline enumerators from more than one \CFA enumeration, forming a tree-like hierarchy.
-However, the uniqueness of enumeration name applies to enumerators, including those 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 from both an enumeration and its supertype, or two enumerations with a 
-common supertype (the diamond problem), since such would unavoidably introduce duplicate enumerator labels. 
-
-
-% 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.
-
-
-
-% The enumeration type for the inheriting type must be the same as the inherited type;
-% 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.
-
-
-% The enumeration base for the subtype must be the same as the super type. 
+However, the uniqueness of enumeration name applies to enumerators, including those 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 from both an enumeration and its supertype, or two enumerations with a
+common supertype (the diamond problem), since such would unavoidably introduce duplicate enumerator labels.
+
 The base type must be consistent between subtype and supertype.
-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 };
-enum() Squamata { Snake, Lizard };
-enum() Lepidosauromorpha { inline Phynchocephalia, inline Squamata, Kuehneosauridae };
-\end{cfa}
-Snake, for example, has the position 0 in Squamata, but 1 in Lepidosauromorpha as Tuatara inherited from Phynchocephalia is position 0 in Lepidosauromorpha.
+When an enumeration inherits enumerators from another enumeration, it copies the enumerators' @value@ and @label@, even if the @value@ is auto initialized.
+However, the position of the underlying representation is the order of the enumerator in the new enumeration.
+\begin{cfa}
+enum() E1 { A };
+enum() E2 { B, C };
+enum() E3 { inline E1, inline E2, D };
+\end{cfa}
+Here, @A@ has position 0 in @E1@ and @E3@.
+@B@ has position 0 in @E2@ and 1 in @E3@.
+@C@ has position 1 in @E2@ and position 2 in @E3@.
+@D@ has position 3 in @E3@.
 
 A subtype enumeration can be casted, or implicitly converted into its supertype, with a @safe@ cost.
 \begin{cfa}
-enum Squamata squamata_lizard = Lizard;
-posn(quamata_lizard); // 1
-enum Lepidosauromorpha lepidosauromorpha_lizard = squamata_lizard;
-posn(lepidosauromorpha_lizard); // 2
-void foo( Lepidosauromorpha l );
-foo( squamata_lizard );
-posn( (Lepidosauromorpha) squamata_lizard ); // 2
-
-Lepidosauromorpha s = Snake;
-\end{cfa}
-The last expression in the preceding example is unambiguous. While both @Squamata.Snake@ and @Lepidosauromorpha.Snake@ are valid candidate, @Squamata.Snake@ has
-an associated safe cost and \CFA select the zero cost candidate @Lepidosauromorpha.Snake@. 
-
-As discussed in \VRef{s:OpaqueEnum}, \CFA chooses position as a representation of \CFA enum. Conversion involves both change of typing
-and possibly @position@.
-
-When converting a subtype to a supertype, the position can only be a larger value. The difference between the position in subtype and in supertype is an "offset".
-\CFA runs a the following algorithm to determine the offset for an enumerator to a super type. 
-% In a summary, \CFA loops over members (include enumerators and inline enums) of the supertype.
-% If the member is the matching enumerator, the algorithm returns its position.
-% If the member is a inline enumeration, the algorithm trys to find the enumerator in the inline enumeration. If success, it returns the position of enumerator in the inline enumeration, plus 
-% the position in the current enumeration. Otherwises, it increase the offset by the size of inline enumeration.
-
+enum E2 e2 = C;
+posn( e2 );                     $\C[1.75in]{// 1}$
+enum E3 e3 = e2;
+posn( e2 );                     $\C{// 2}$
+void foo( E3 e );
+foo( e2 );
+posn( (E3)e2 );         $\C{// 2}$
+E3 e31 = B;
+posn( e31 );            $\C{// 1}\CRT$
+\end{cfa}
+The last expression is unambiguous.
+While both @E2.B@ and @E3.B@ are valid candidate, @E2.B@ has an associated safe cost and \CFA selects the zero cost candidate @E3.B@.
+Hence, as discussed in \VRef{s:OpaqueEnum}, \CFA chooses position as a representation of the \CFA enum.
+Therefore, conversion involves both a change of type and possibly position.
+
+When converting a subtype to a supertype, its position can only be a larger value.
+The difference between the position in the subtype and in the supertype is its \newterm{offset}.
+\VRef[Figure]{s:OffsetSubtypeSuperType} show the algorithm to determine the offset for an subtype enumerator to its super type.
+\PAB{You need to explain the algorithm.}
+
+\begin{figure}
 \begin{cfa}
 struct Enumerator;
@@ -280 +263 @@
 pair<bool, int> calculateEnumOffset( CFAEnum dst, Enumerator e ) {
         int offset = 0;
-        for( auto v: dst.members ) {
+        for ( auto v: dst.members ) {
                 if ( v.holds_alternative<Enumerator>() ) {
                         auto m = v.get<Enumerator>();
@@ -294 +277 @@
 }
 \end{cfa}
-
-% \begin{cfa}
-% Names fred = Name.Fred;
-% (Names2) fred; (Names3) fred; (Name3) Names.Jack;  $\C{// cast to super type}$
-% Names2 fred2 = fred; Names3 fred3 = fred2; $\C{// assign to super type}$
-% \end{cfa}
+\caption{Compute Offset from Subtype Enumerator to Super Type}
+\label{s:OffsetSubtypeSuperType}
+\end{figure}
+
 For the given function prototypes, the following calls are valid.
 \begin{cquote}
@@ -319 +300 @@
 \end{cquote}
 Note, the validity of calls is the same for call-by-reference as for call-by-value, and @const@ restrictions are the same as for other types.
+
 
 \section{Enumerator Control Structures}
@@ -379 +361 @@
 \begin{cfa}
 for ( cx; @Count@ ) { sout | cx | nonl; } sout | nl;
-for ( cx; +~= Count ) { sout | cx | nonl; } sout | nl;
+for ( cx; ~= Count ) { sout | cx | nonl; } sout | nl;
 for ( cx; -~= Count ) { sout | cx | nonl; } sout | nl;
 First Second Third Fourth
@@ -390 +372 @@
 C has an idiom for @if@ and loop predicates of comparing the predicate result ``not equal to 0''.
 \begin{cfa}
-if ( x + y /* != 0 */ ) ...
-while ( p /* != 0 */ ) ...
+if ( x + y /* != 0 */  ) ...
+while ( p /* != 0 */  ) ...
 \end{cfa}
 This idiom extends to enumerations because there is a boolean conversion in terms of the enumeration value, if and only if such a conversion is available.
@@ -412 +394 @@
 \section{Enumeration Dimension}
 
-\VRef{s:EnumeratorTyping} introduced the harmonizing problem between an enumeration and secondary information.
+\VRef{s:EnumeratorTyping} introduces the harmonizing problem between an enumeration and secondary information.
 When possible, using a typed enumeration for the secondary information is the best approach.
 However, there are times when combining these two types is not possible.
@@ -422 +404 @@
 enum E1 { A, B, C, N }; // possibly predefined
 enum(int) E2 { A, B, C };
-float H1[N] = { [A] :$\footnote{Note, C uses the symbol, @'='@ for designator initialization, but \CFA had to change to @':'@ because of problems with tuple syntax.}$ 3.4, [B] : 7.1, [C] : 0.01 }; // C
+float H1[N] = { [A] :$\footnotemark$ 3.4, [B] : 7.1, [C] : 0.01 }; // C
 float H2[@E2@] = { [A] : 3.4, [B] : 7.1, [C] : 0.01 }; // CFA
 \end{cfa}
+\footnotetext{C uses symbol \lstinline{'='} for designator initialization, but \CFA changes it to \lstinline{':'} because of problems with tuple syntax.}
 This approach is also necessary for a predefined typed enumeration (unchangeable), when additional secondary-information need to be added.
 
-The array subscript operator, namely ?[?], has been overloaded so that when a CFA enumerator is used as an array index, it implicitly converts 
-to its position over value to sustain data hormonization. User can revert the behaviour by:
-\begin{cfa}
-float ?[?](float * arr, E2 index) { return arr[value(index)]; }
-\end{cfa}
-When an enumeration type is being used as an array dimension, \CFA add the enumeration type to initializer's context. As a result, 
-@H2@'s array destinators @A@, @B@ and @C@ are resolved unambiguously to type E2. (H1's destinators are also resolved unambiguously to 
-E1 because E2 has a @value@ cost to @int@).
+The array subscript operator, namely @?[?]@, is overloaded so that when a \CFA enumerator is used as an array index, it implicitly converts to its position over value to sustain data harmonization.
+This behaviour can be reverted by explicit overloading:
+\begin{cfa}
+float ?[?]( float * arr, E2 index ) { return arr[ value( index ) ]; }
+\end{cfa}
+When an enumeration type is being used as an array dimension, \CFA adds the enumeration type to the initializer's context.
+As a result, @H2@'s array destinators @A@, @B@ and @C@ are resolved unambiguously to type @E2@.
+(@H1@'s destinators are also resolved unambiguously to @E1@ because @E2@ has a @value@ cost.)
+
 
 \section{Enumeration I/O}
@@ -443 +427 @@
 \VRef[Figure]{f:EnumerationI/O} show \CFA enumeration input based on the enumerator labels.
 When the enumerator labels are packed together in the input stream, the input algorithm scans for the longest matching string.
-For basic types in \CFA, the constants use to initialize a variable in a program are available to initialize a variable using input, where strings constants can be quoted or unquoted.
+For basic types in \CFA, the rule is that the same constants used to initialize a variable in a program are available to initialize a variable using input, where strings constants can be quoted or unquoted.
 
 \begin{figure}
@@ -509 +493 @@
 \small
 \begin{cfa}
-struct MR { double mass, radius; };                     $\C{// planet definition}$
+struct MR { double mass, radius; };                     $\C[3.5in]{// planet definition}$
 enum( @MR@ ) Planet {                                           $\C{// typed enumeration}$
         //                      mass (kg)   radius (km)
@@ -543 +527 @@
                 sout | rp | "is not a planet";
         }
-        for ( @p; Planet@ ) {                                   $\C{// enumerate}$
+        for ( @p; Planet@ ) {                                   $\C{// enumerate}\CRT$
                 sout | "Your weight on" | ( @p == MOON@ ? "the" : " " ) | p
                            | "is" | wd( 1,1,  surfaceWeight( p, earthMass ) ) | "kg";

doc/theses/jiada_liang_MMath/background.tex

@@ -235 +235 @@
 
 \subsection{Function Overloading}
-Function overloading is programming languages feature wherein functions may share the same name, but with different function signatures. In both C++ and \CFA, function names can be overloaded 
+Function overloading is programming languages feature wherein functions may share the same name, but with different function signatures. In both C++ and \CFA, function names can be overloaded
 with different entities as long as they are different in terms of the number and type of parameters.
 
@@ -381 +381 @@
 \end{cfa}
 The @identity@ function accepts a value from any type as an argument and returns that value.
-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. 
+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.
 \begin{cfa}
 forall( T @| { void foo( T ); }@ ) void bar( T t ) { @foo( t );@ }
@@ -394 +394 @@
 \subsection{Trait}
 A @forall@ clause can asserts on multiple types and with multiple asserting functions. A common practice in \CFA is to group
-the asserting functions in to a named \newterm{trait}. 
+the asserting functions in to a named \newterm{trait}.
 
 \subsection{Trait}
 
 A @forall@ clause can assert many restrictions on multiple types.
-A common practice is to refactor the assertions into a named \newterm{trait}. 
+A common practice is to refactor the assertions into a named \newterm{trait}.
 \begin{cfa}
 forall(T) trait @Bird@ {
@@ -434 +434 @@
 otherwise, the program becomes littered with many explicit casts, which is not match programmer expectation.
 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. 
+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}.
 
@@ -447 +447 @@
 @safe@ is sum of the degree of safe (widening) conversions.
 \end{enumerate}
-Sum of degree is a method to quantify C's integer and floating-point rank. 
+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.
@@ -494 +494 @@
 
 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.
-Cast cost exists as an independent matrix for conversion that cannot happen implcitly, while being possible with an explicit cast. These conversions are often defined to have 
+Cast cost exists as an independent matrix for conversion that cannot happen implcitly, while being possible with an explicit cast. These conversions are often defined to have
 infinite conversion cost and non-infinite cast cost.

doc/theses/jiada_liang_MMath/intro.tex

@@ -299 +299 @@
 \begin{enumerate}
 \item
-overloading: 
+overloading:
 \item
 scoping