Changes in / [5aeb1a9:878b1385]

Location:

doc/theses/jiada_liang_MMath

Files:

• CFAenum.tex (modified) (7 diffs)
• background.tex (modified) (4 diffs)
• implementation.tex (modified) (1 diff)

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{clang}[identifierstyle=\linespread{0.9}\it]
-$\it enum$-specifier:
-        enum @(type-specifier$\(_{opt}\)$)@ identifier$\(_{opt}\)$ { cfa-enumerator-list }
-        enum @(type-specifier$\(_{opt}\)$)@ identifier$\(_{opt}\)$ { cfa-enumerator-list , }
-        enum @(type-specifier$\(_{opt}\)$)@ identifier
-cfa-enumerator-list:
-        cfa-enumerator
-        cfa-enumerator, cfa-enumerator-list
-cfa-enumerator:
-        enumeration-constant
-        $\it inline$ identifier
-        enumeration-constant = expression
-\end{clang}
-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 "opaque enums".
-Otherwise, \CFA enum with type declaration are "typed enums".
-
-\section{Opaque Enum}
-\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 syntax 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 opage enum has two @attributes@: @position@ and @label@. \CFA auto-generates @attribute functions@ @posn()@ and @label()@ for every \CFA enum to returns the respective attributes.
-\begin{cfa}
-// Auto-generated
-int posn(Planet p);
-char * s label(Planet p);
-\end{cfa}
-
-\begin{cfa}
-unsigned i = posn(VENUS); // 1
-char * s = label(MARS); // "MARS"
-\end{cfa}
-
-% \subsection{Representation}
-\CFA uses chooses signed int as the underlying representation of an opaque enum variable, holding the value of enumeration position. Therefore, @posn()@ is in fact a cast that bypassing type system, converting an 
-cfa enum to its integral representation.
-
-Labels information are stored in a global array. @label()@ is a function that maps enum position to an element of the array.
-
-\section{Typed Enum}
+
+\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.
+
+
+\section{Aliasing}
+
+{\color{red}@***@}
+C already provides @const@-style aliasing using the unnamed enumerator \see{\VRef{s:TypeName}}, even if the keyword @enum@ is misleading (@const@ is better).
+However, given the existence of this form, it is straightforward to extend it with heterogeneous types, \ie types other than @int@.
+\begin{cfa}
+enum { Size = 20u, PI = 3.14159L, Jack = L"John" }; $\C{// not an ADT nor an enumeration}$
+\end{cfa}
+which matches with @const@ aliasing in other programming languages.
+(See \VRef{s:CenumImplementation} on how @gcc@/@clang@ are doing this for integral types.)
+Here, the type of each enumerator is the type of the initialization constant, \eg @typeof(20u)@ for @Size@ implies @unsigned int@.
+Auto-initialization is impossible in this case because some types do not support arithmetic.
+As seen in \VRef{s:EnumeratorTyping}, this feature is just a shorthand for multiple typed-enumeration declarations.
+
+
+\section{Enumerator Visibility}
+\label{s:EnumeratorVisibility}
+
+In C, unscoped enumerators present a \newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names.
+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.
+Furthermore, \CFA uses the environment, such as the left-hand of assignment and function arguments, to pinpoint the best overloaded name.
+\VRef[Figure]{f:EnumeratorVisibility} shows enumeration overloading and how qualification and casting are used to disambiguate ambiguous situations.
+\CFA overloading allows programmers to use the most meaningful names without fear of name clashes within a program or from external sources, like include files.
+Experience from \CFA developers is that the type system implicitly and correctly disambiguates the majority of overloaded names.
+That is, it is rare to get an incorrect selection or ambiguity, even among hundreds of overloaded variables and functions, that requires disambiguation using qualification or casting.
+
+\begin{figure}
+\begin{cfa}
+enum E1 { First, Second, Third, Fourth };
+enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$
+E1 f() { return Third; }                                $\C{// overloaded functions, 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{Enumerator Scoping}
+
+An enumeration 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}
+{\color{red}@***@}It is possible to toggle back to unscoped using the \CFA @with@ 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: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.
+
+
+\section{Enumerator Typing}
 \label{s:EnumeratorTyping}
 
@@ -59 +89 @@
 Note, 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@.
+
+C has an implicit type conversion from an enumerator to its base type @int@.
+Correspondingly, \CFA has an implicit (safe) conversion from a typed enumerator to its base type.
+\begin{cfa}
+char currency = Dollar;
+string fred = Fred;                                             $\C{// implicit conversion from char * to \CFA string type}$
+Person student = Beth;
+\end{cfa}
+
+% \begin{cfa}
+% struct S { int i, j; };
+% enum( S ) s { A = { 3,  4 }, B = { 7,  8 } };
+% enum( @char@ ) Currency { Dollar = '$\textdollar$', Euro = '$\texteuro$', Pound = '$\textsterling$'  };
+% enum( @double@ ) Planet { Venus = 4.87, Earth = 5.97, Mars = 0.642  }; // mass
+% enum( @char *@ ) Colour { Red = "red", Green = "green", Blue = "blue"  };
+% enum( @Currency@ ) Europe { Euro = '$\texteuro$', Pound = '$\textsterling$' }; // intersection
+% \end{cfa}
 
 \begin{figure}
@@ -73 +120 @@
         int i, j, k;
         enum( @int *@ ) ptr { I = &i,  J = &j,  K = &k };
-        enum( @int &@ ) ref { I = i,   J = j,   K = k };
+@***@enum( @int &@ ) ref { I = i,   J = j,   K = k };
 // tuple
-        enum( @[int, int]@ ) { T = [ 1, 2 ] }; $\C{// new \CFA type}$
+@***@enum( @[int, int]@ ) { T = [ 1, 2 ] }; $\C{// new \CFA type}$
 // function
         void f() {...}   void g() {...}
@@ -103 +150 @@
 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{Implicit Conversion}
-C has an implicit type conversion from an enumerator to its base type @int@.
-Correspondingly, \CFA has an implicit (safe) conversion from a typed enumerator to its base type.
-\begin{cfa}
-char currency = Dollar;
-string fred = Fred;                                             $\C{// implicit conversion from char * to \CFA string type}$
-Person student = Beth;
-\end{cfa}
-
-% The implicit conversion is accomplished by the compiler adding @value()@ function calls as a candidate with safe cost. Therefore, the expression
-% \begin{cfa}
-% char currency = Dollar;
-% \end{cfa}
-% is equivalent to
-% \begin{cfa}
-% char currency = value(Dollar);
-% \end{cfa}
-% Such conversion an @additional@ safe 
-
-The implicit conversion is accomplished by the resolver adding call to @value()@ functions as a resolution candidate with a @implicit@ cost.
-Implicit cost is an additional category to Aaron's cost model. It is more signicant than @unsafe@ to have
-the compiler choosing implicit conversion over the narrowing conversion; It is less signicant to @poly@ 
-so that function overloaded with enum traits will be selected over the implicit. @Enum trait@ will be discussed in the chapter.
-
-Therefore, \CFA conversion cost is 8-tuple
-@@(unsafe, implicit, poly, safe, sign, vars, specialization, reference)@@
-
-\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 can be generalized in \CFA through the trait @AutoInitializable@.
-% \begin{cfa}
-% forall(T) @trait@ AutoInitializable {
-%       void ?{}( T & o, T v );                         $\C{// initialization}$
-%       void ?{}( T & t, zero_t );                      $\C{// 0}$
-%       T ?++( T & t);                                          $\C{// increment}$
-% };
-% \end{cfa}
-% In addition, there is an implicit enumeration counter, @ecnt@ of type @T@, managed by the compiler.
-% For example, the type @Odd@ satisfies @AutoInitializable@:
-% \begin{cfa}
-% struct Odd { int i; };
-% void ?{}( Odd & o, int v ) { if ( v & 1 ) o.i = v; else /* error not odd */ ; };
-% void ?{}( Odd & o, zero_t ) { o.i = 1; };
-% Odd ?++( Odd o ) { return (Odd){ o.i + 2 }; };
-% \end{cfa}
-% and implicit initialization is available.
-% \begin{cfa}
-% enum( Odd ) { A, B, C = 7, D };                       $\C{// 1, 3, 7, 9}$
-% \end{cfa}
-% where the compiler performs the following transformation and runs the code.
-% \begin{cfa}
-% enum( Odd ) {
-%       ?{}( ecnt, @0@ }  ?{}( A, ecnt },       ?++( ecnt )  ?{}( B, ecnt ),
-%       ?{}( ecnt, 7 )  ?{}( C, ecnt ), ?++( ecnt )  ?{}( D, ecnt )
-% };
-% \end{cfa}
-
-The notion of auto-initialization is generalized in \CFA enum in the following way:
-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.
-\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.
-
+
+\section{Opaque Enumeration}
+
+\CFA provides a special opaque (pure) enumeration type with only assignment and equality operations, and no implicit conversion to any base-type.
+\begin{cfa}
+enum@()@ Mode { O_RDONLY, O_WRONLY, O_CREAT, O_TRUNC, O_APPEND };
+Mode mode = O_RDONLY;
+if ( mode == O_CREAT ) ...
+bool b = mode == O_RDONLY || mode @<@ O_APPEND; $\C{// disallowed}$
+int www @=@ mode;                                               $\C{// disallowed}$
+\end{cfa}
+
+
+\section{Enumeration Operators}
+
+
+\subsection{Conversion}
+
+\CFA only proves an implicit safe conversion between an enumeration and its base type (like \CC), whereas C allows an unsafe conversion from base type to enumeration.
+\begin{cfa}
+enum(int) Colour { Red, Blue, Green };
+int w = Red;            $\C[1.5in]{// allowed}$
+Colour color = 0;       $\C{// disallowed}\CRT$
+\end{cfa}
+Unfortunately, there must be one confusing case between C enumerations and \CFA enumeration for type @int@.
+\begin{cfa}
+enum Colour { Red = 42, Blue, Green };
+enum(int) Colour2 { Red = 16, Blue, Green };
+int w = Redy;           $\C[1.5in]{// 42}\CRT$
+\end{cfa}
+Programmer intuition is that the assignment to @w@ is ambiguous.
+However, converting from @color@ to @int@ is zero cost (no conversion), while from @Colour2@ to @int@ is a safe conversion, which is a higher cost.
+This semantics means fewer backwards-compatibility issues with overloaded C and \CFA enumerators.
+
+
+\subsection{Properties}
+
+\VRef{s:Terminology} introduced three fundamental enumeration properties: label, position, and value.
+\CFA provides direct access to these three properties via the functions: @label@, @posn@, and @value@.
+\begin{cfa}
+enum( const char * ) Name { Fred = "FRED", Mary = "MARY", Jane = "JANE" };
+Name name = Fred;
+sout | name | label( name ) | posn( name ) | value( name );
+FRED Fred 0 FRED
+\end{cfa}
+The default meaning for an enumeration variable in an expression is its value.
+
+
+\subsection{Range}
+
+The following helper function are used to access and control enumeration ranges (enumerating).
+
+The pseudo-function @countof@ (like @sizeof@) provides the size (range) of an enumeration or an enumeration instance.
+\begin{cfa}
+enum(int) Colour { Red, Blue, Green };
+Colour c = Red
+sout | countof( Colour ) | countof( c );
+3 3
+\end{cfa}
+@countof@ is a pseudo-function because it takes a type as an argument.
+The function @fromInt@ provides a safe subscript of the enumeration.
+\begin{cfa}
+Colour r = fromInt( prng( countof( Colour ) ) ); // select random colour
+\end{cfa}
+The functions @lowerBound@, @upperBound@, @succ@, and @pred@ are for enumerating.
+\begin{cfa}
+for ( Colour c = lowerBound();; ) {
+        sout | c | nonl;
+  if ( c == upperBound() ) break;
+        c = succ( c );
+}
+\end{cfa}
+Note, the mid-exit loop is necessary to prevent triggering a @succ@ bound check, as in:
+\begin{cfa}
+for ( Colour c = lowerBound(); c <= upperBound(); c = succ( c ) ) ... // generates error
+\end{cfa}
+When @c == upperBound()@, the loop control still invokes @succ( c )@, which causes an @enumBound@ exception.
+Finally, there is operational overlap between @countof@ and @upperBound@.
 
 
@@ -188 +233 @@
 
 \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).
-
-\begin{cfa}
-enum( char * ) Names { /* as above */ };
-enum( char * ) Names2 { @inline Names@, Jack = "JACK", Jill = "JILL" };
-enum( char * ) Names3 { @inline Names2@, Sue = "SUE", Tom = "TOM" };
-\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@.
+\begin{cfa}
+enum( const char * ) Names { Fred = "FRED", Mary = "MARY", Jane = "JANE" };
+enum( const char * ) Names2 { @inline Names@, Jack = "JACK", Jill = "JILL" };
+enum( const char * ) Names3 { @inline Names2@, Sue = "SUE", Tom = "TOM" };
+\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.
 
@@ -203 +246 @@
 Specifically, the inheritance relationship for @Names@ is:
 \begin{cfa}
-Names $\(\subset\)$ Names2 $\(\subset\)$ Names3 $\C{// enum type of Names}$
-\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@.
-\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.
-
-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 umabigious. 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.
-
-\begin{cfa}
-struct Enumerator;
-struct CFAEnum {
-        vector<variant<CFAEnum, Enumerator>> members;
-};
-pair<bool, int> calculateEnumOffset( CFAEnum dst, Enumerator e ) {
-        int offset = 0;
-        for( auto v: dst.members ) {
-                if ( v.holds_alternative<Enumerator>() ) {
-                        auto m = v.get<Enumerator>();
-                        if ( m == e ) return make_pair( true, 0 );
-                        offset++;
-                } else {
-                        auto p = calculateEnumOffset( v, e );
-                        if ( p.first ) return make_pair( true, offset + p.second );
-                        offset += p.second;
-                }
-        }
-        return make_pair( false, offset );
-}
-\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}
+Names  $\(\subset\)$  Names2  $\(\subset\)$  Names3  $\C{// enum type of Names}$
+\end{cfa}
+A subtype can be cast to its supertype, assigned to a supertype variable, or used as a function argument that expects the supertype.
+\begin{cfa}
+Names fred = Names.Fred;
+(Names2)fred;   (Names3)fred;   (Names3)Names2.Jack;  $\C{// cast to super type}$
+Names2 fred2 = fred;   Names3 fred3 = fred2;    $\C{// assign to super type}$
+\end{cfa}
+As well, there is the implicit cast to an enumerator's base-type.
+\begin{cfa}
+const char * name = fred;
+\end{cfa}
 For the given function prototypes, the following calls are valid.
 \begin{cquote}
@@ -286 +277 @@
 \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}

doc/theses/jiada_liang_MMath/background.tex

@@ -51 +51 @@
         int va[r];
 }
+
+
 \end{clang}
 \end{tabular}
@@ -57 +59 @@
 Dynamically initialized identifiers may appear in initialization and array dimensions in @g++@, which allows variable-sized arrays on the stack.
 Again, this form of aliasing is not an enumeration.
+
 
 \section{C Enumeration}
@@ -154 +157 @@
 Hence, initialization in the range @INT_MIN@..@INT_MAX@ is 4 bytes, and outside this range is 8 bytes.
 
+
 \subsection{Usage}
 \label{s:Usage}
@@ -217 +221 @@
 \bigskip
 While C provides a true enumeration, it is restricted, has unsafe semantics, and does not provide useful enumeration features in other programming languages.
-
-\section{\CFA Polymorphism}
-\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 
-with different entities as long as they are different in terms of the number and type of parameters.
-
-\begin{cfa}
-void f(); // (1)
-void f(int); // (2); Overloaded on the number of parameters
-void f(char); // (3); Overloaded on parameter type
-
-f('A');
-\end{cfa}
-In this case, the name f is overloaded with a nullity function and two arity functions with different parameters types. Exactly which precedures being executed
-is determined based on the passing arguments. The last expression of the preceding example calls f with one arguments, narrowing the possible candidates down to (2) and (3).
-Between those, function argument 'A' is an exact match to the parameter expected by (3), while needing an @implicit conversion@ to call (2). The compiler determines (3) is the better candidates among
-and procedure (3) is being executed.
-
-\begin{cfa}
-int f(int); // (4); Overloaded on return type
-[int, int] f(int); // (5) Overloaded on the number of return value
-\end{cfa}
-The function declarations (4) and (5) show the ability of \CFA functions overloaded with different return value, a feature that is not shared by C++.
-
-
-\subsection{Operator Overloading}
-Operators in \CFA are specialized function and are overloadable by with specially-named functions represents the syntax used to call the operator.
-% For example, @bool ?==?T(T lhs, T rhs)@ overloads equality operator for type T, where @?@ is the placeholders for operands for the operator.
-\begin{cfa}
-enum Weekday { Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday };
-bool ?<?(const Weekday a, const Weekday b) {
-        return ((int)a + 1);
-}
-Monday < Sunday; // False
-?<?( Monday, Sunday ); // Equivalent syntax
-\end{cfa}
-Unary operators are functions that takes one argument and have name @operator?@ or @?operator@, where @?@ is the placeholders for operands.
-Binary operators are function with two parameters. They are overloadable with function name @?operator?@.
-
-\subsection{Constructor and Destructor}
-In \CFA, all objects are initialized by @constructors@ during its allocation, including basic types, 
-which are initialized by auto-generated basic type constructors.
-
-Constructors are overloadable functions with name @?{}@, return @void@, and have at least one parameter, which is a reference
-to the object being constructored (Colloquially referred to "this" or "self" in other language).
-
-\begin{cfa}
-struct Employee {
-        const char * name;
-        double salary;
-};
-
-void ?{}( Employee& this, const char * name, double salary ) {
-    this.name = name;
-    this.salary = salary;
-}
-
-Employee Sara { "Sara Schmidt", 20.5 };
-\end{cfa}
-Like Python, the "self" reference is implicitly passed to a constructor. The Employee constructors takes two additional arugments used in its
-field initialization.
-
-A destructor in \CFA is a function that has name @^?{}@. It returns void, and take only one arugment as its "self".
-\begin{cfa}
-void ^?{}( Employee& this ) {
-    free(this.name);
-    this.name = 0p;
-    this.salary = 0;
-}
-\end{cfa}
-Destructor can be explicitly evoked as a function call, or implicitly called at the end of the block in which the object is delcared.
-\begin{cfa}
-{
-^Sara{};
-Sara{ "Sara Craft", 20 };
-} // ^Sara{}
-\end{cfa}
-
-\subsection{Variable Overloading}
-C and C++ disallow more than one variable declared in the same scope with the same name. When a variable declare in a inner scope has the same name as 
-a variable in an outer scope, the outer scope variable is "shadowed" by the inner scope variable and cannot be accessed directly. 
-
-\CFA has variable overloading: multiple variables can share the same name in the same scope, as long as they have different type. Name shadowing only 
-happens when the inner scope variable and the outer scope ones have the same type.
-\begin{cfa}
-double i = 6.0;
-int i = 5;
-void foo( double i ) { sout | i; } // 6.0
-\end{cfa}
-
-\subsection{Special Literals}
-Literal 0 has special meanings within different contexts: it can means "nothing" or "empty", an additive identity in arithmetic, a default value as in C (null pointer), 
-or an initial state.
-Awaring of its significance, \CFA provides a special type for the 0 literal, @zero_t@, to define the logical @zero@ for custom types.
-\begin{cfa}
-struct S { int i, j; };
-void ?{}( S & this, @zero_t@ ) { this.i = 0; this.j = 0; } // zero_t, no parameter name allowed
-S s0 = @0@;
-\end{cfa}
-Overloading @zero_t@ for S provides new definition for @zero@ of type S.
-
-According to the C standard, @0@ is the @only@ false value. Any values compares equals to @0@ is false, and not euqals @0@ is true. As a consequence, control structure 
-such as @if()@ and @while()@ only runs it true clause when its predicate @not equals@ to @0@. 
-
-\CFA generalizes this concept and allows to logically overloads the boolean value for any type by overloading @not equal@ comparison against @zero_t@.
-\begin{cfa}
-int ?@!=@?( S this, @zero_t@ ) { return this.i != 0 && this.j != 0; }
-\end{cfa}
-
-% In C, the literal 0 represents the Boolean value false. The expression such as @if (x)@ is equivalent to @if (x != 0)@ .
-% \CFA allows user to define the logical zero for a custom type by overloading the @!=@ operation against a special type, @zero_t@, 
-% so that an expression with the custom type can be used as a predicate without the need of conversion to the literal 0.
-% \begin{cfa}
-% struct S s;
-% int ?!=?(S, zero_t);
-% if (s) {}
-% \end{cfa}
-Literal 1 is also special. Particularly in C, the pre-increment operator and post-increment operator can be interpreted in terms of @+= 1@.
-The logical @1@ in \CFA is represented by special type @one_t@.
-\begin{cfa}
-void ?{}( S & this, one_t ) { this.i = 1; this.j = 1; } // one_t, no parameter name allowed
-S & ?+=?( S & this, one_t ) { this.i += 1; this.j += 1; return op; }
-\end{cfa}
-Without explictly overloaded by a user, \CFA uses the user-defined @+=(S&, one_t)@ to interpret @?++@ and @++?@, as both are polymorphic functions in \CFA.
-
-\subsection{Polymorphics Functions}
-Parametric-Polymorphics functions are the functions that applied to all types. \CFA functions are parametric-polymorphics when 
-they are written with the @forall@ clause.
-
-\begin{cfa}
-forall(T)
-T identity(T x) { return x; }
-identity(42);
-\end{cfa}
-The identity function accepts a value from any type as an arugment, and the type parameter @T@ is bounded to @int@ when the function
-is called with 42. 
-
-The forall clause can takes @type assertions@ that restricts the polymorphics type. 
-\begin{cfa}
-forall( T | { void foo(T); } )
-void bar(T t) { foo(t); }
-
-struct S {} s;
-void foo(struct S);
-
-bar(s);
-\end{cfa}
-The assertion on @T@ restricts the range of types for bar to only those implements foo with the matching a signature, so that bar() 
-can call @foo@ in its body with type safe.
-Calling on type with no mathcing @foo()@ implemented, such as int, causes a compile time type assertion error. 
-
-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 @trait@ . 
-
-\begin{cfa}
-trait Bird(T) {
-        int days_can_fly(T i);
-        void fly(T t);
-};
-
-forall(B | Bird(B)) {
-        void bird_fly(int days_since_born, B bird) {
-                if (days_since_born > days_can_fly(bird)) {
-                        fly(bird);
-                }
-        }
-}
-
-struct Robin {} r;
-int days_can_fly(Robin r) { return 23; }
-void fly(Robin r) {}
-
-bird_fly( r );
-\end{cfa}
-
-Grouping type assertions into named trait effectively create a reusable interface for parametrics polymorphics types.
-
-\section{Expression Resolution}
-
-The overloading feature poses a challenge in \CFA expression resolution. Overloadeded identifiers can refer multiple 
-candidates, with multiples being simultaneously valid. The main task of \CFA resolver is to identity a best candidate that
-involes less implicit conversion and polymorphism.
-
-\subsection{Conversion Cost}
-In C, functions argument and parameter type does not need to be exact match, and the compiler performs an @implicit conversion@ on argument.
-\begin{cfa}
-void foo(double i);
-foo(42);
-\end{cfa}
-The implicit conversion in C is relatively simple because of the abscence of overloading, with the exception of binary operators, for which the 
-compiler needs to find a common type of both operands and the result. The pattern is known as "usual arithmetic conversions".
-
-\CFA generalizes C implicit conversion to function overloading as a concept of @conversion cost@.
-Initially designed by Bilson, conversion cost is a 3-tuple, @(unsafe, poly, safe)@, where unsafe is the number of narrowing conversion,
-poly is the count of polymorphics type binding, and safe is the sum of the degree of widening conversion. Every 
-basic type in \CFA has been assigned with a @distance to Byte@, or @distance@, and the degree of widening conversion is the difference between two distances.
-
-Aaron extends conversion cost to a 7-tuple, 
-@@(unsafe, poly, safe, sign, vars, specialization, reference)@@. The summary of Aaron's cost model is the following:
-\begin{itemize}
-\item Unsafe is the number of argument that implicitly convert to a type with high rank.
-\item Poly accounts for number of polymorphics binding in the function declaration.
-\item Safe is sum of distance (add reference/appendix later).
-\item Sign is the number of sign/unsign variable conversion.
-\item Vars is the number of polymorphics type declared in @forall@.
-\item Specialization is opposite number of function declared in @forall@. More function declared implies more constraint on polymorphics type, and therefore has the lower cost.
-\item Reference is number of lvalue-to-rvalue conversion.
-\end{itemize}

doc/theses/jiada_liang_MMath/implementation.tex

@@ -1 +1 @@
 \chapter{Enumeration Implementation}
+
+
 
 \section{Enumeration Traits}