Context Navigation

-                      r11cced6
+                      rc1c0efdb
 \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 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}
 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{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 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}
+%
+% 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.
 …
 posn( e2 );                     $\C[1.75in]{// 0}$
 enum E3 e3 = e2;        $\C{// Assignment with enumeration conversion E2 to E3}$
 posn( e2 );                     $\C{// 1 }$
+posn( e2 );                     $\C{// 1 cost}$
 void foo( E3 e );
 foo( e2 );                      $\C{// Type compatible with enumeration conversion E2 to E3}$
 posn( (E3)e2 );         $\C{// Explicit cast with enumeration conversion E2 to E3}$
 E3 e31 = B;                     $\C{// No conversion: E3.B}$
 posn( e31 );            $\C{// 0 }\CRT$
+posn( e31 );            $\C{// 0 cost}\CRT$
 \end{cfa}
 The last expression is unambiguous.
+While both @E2.B@ and @E3.B@ are valid candidates, @E2.B@ has an associated safe cost and @E3.B@ need not a conversion (@zero@ cost). \CFA selects the lowest cost candidate @E3.B@.
+While both @E2.B@ and @E3.B@ are valid candidates, @E2.B@ has an associated safe cost and @E3.B@ needs no conversion (@zero@ cost).
+\CFA selects the lowest cost candidate @E3.B@.
 For the given function prototypes, the following calls are valid.
 …
 \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 @?[?]@, 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:
 …
 float ?[?]( float * arr, E2 index ) { return arr[ value( index ) ]; }
 \end{cfa}
 While enumerator labels @A@, @B@ and @C@ are being defined twice in different enumerations, they are
+unambiguous within the context. Designators in H1 are unambiguous becasue @E2@ has a @value@ cost to @int@, which
+is more expensive than @safe@ cost from C-Enum @E1@ to @int@. On the hand, designators in @H2@ are resolved as @E2@ because
+when a \CFA enumeration type is being used as an array dimension, \CFA adds the enumeration type to the initializer's resolution context.
+While enumerator labels @A@, @B@ and @C@ are being defined twice in different enumerations, they are unambiguous within the context.
+Designators in @H1@ are unambiguous becasue @E2@ has a @value@ cost to @int@, which is more expensive than @safe@ cost from C-Enum @E1@ to @int@.
+Designators in @H2@ are resolved as @E2@ because when a \CFA enumeration type is being used as an array dimension, \CFA adds the enumeration type to the initializer's resolution context.
 \section{I/O}
 As seen in multiple examples, \CFA enumerations can be printed and the default property printed is the enumerator's label, which is similar in other programming languages.
 However, very few programming languages provide a mechanism to read in enumerator values.

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset c1c0efdb for doc/theses/jiada_liang_MMath/CFAenum.tex

Legend:

doc/theses/jiada_liang_MMath/CFAenum.tex

Download in other formats: