Context Navigation

-                      rc1c0efdb
+                      r7568e5c
 \chapter{\texorpdfstring{\CFA}{Cforall} Enumeration}
 \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.
+\CFA extends C-Style enumeration by adding a number of new features that bring enumerations in line with other modern programming languages.
+Any enumeration extensions must be intuitive to C programmers in syntax and semantics.
+The following sections detail my new contributions to enumerations in \CFA.
 \section{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:CFAInheritance}} using an @inline@ to another enumeration type.
+\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:CFAInheritance}} using an @inline@ to another enumeration type.
 \begin{cfa}[identifierstyle=\linespread{0.9}\it]
 $\it enum$-specifier:
 …
 A A @0@ 3
 \end{cfa}
 Finally, there is an additional enumeration pseudo-function @countof@ (like @sizeof@, @typeof@) that returns the number of enumerators in an enumeration.
+Finally, \CFA introduces an additional enumeration pseudo-function @countof@ (like @sizeof@, @typeof@) that returns the number of enumerators in an enumeration.
 \begin{cfa}
 enum(int) E { A, B, C, D } e;
 …
 countof( e );  // 4, variable argument
 \end{cfa}
 This buildin function replaces the C idiom for automatically computing the number of enumerators \see{\VRef{s:Usage}}.
+This built-in 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
 …
 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.
+Attribute function @posn@ performs type substitution on an expression from \CFA type to an integral type.
+The label and value of an enumerator are 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 backward compatibility means the necessary backing data structures cannot be supplied.
 …
 \label{s:OpaqueEnum}
 When an enumeration type is empty is it an \newterm{opaque} enumeration.
+When an enumeration type is empty. it is 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.
+Here, the compiler chooses the internal representation, which is hidden, so the enumerators cannot be initialized.
+Compared to the C enum, opaque enums are more restrictive regarding 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@.
+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.
+Equality and relational operations are available.
 \begin{cfa}
 if ( mode @==@ O_CREAT ) ...
 …
 \label{s:EnumeratorTyping}
 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 use of the synonyms @Liz@ and @Beth@ in the last declaration.
+When an enumeration type is specified, all enumerators have that type and can be initialized with constants of that type or compile-time convertible to that type.
+Figure~\ref{f:EumeratorTyping} shows a series of examples illustrating that all \CFA types can be used with an enumeration, and each type's values are used to set the enumerator constants.
+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@.
 …
 };
 \end{cfa}
 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.
+Note that 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 \emph{not} used to evaluate an enumerator's value.
 …
 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@.
+Here, the candidate (1) has a @value@ conversion cost to convert to the base type, while the candidate (2) has an @unsafe@ conversion from @double@ to @int@,
+which is a more expensive conversion.
 Hence, @bar( x )@ resolves @x@ as type @Math@.
 …
 % \section{Auto Initialization}
+%
+\section{Auto Initialization}
+\CFA implements auto-initialization for both C enumerations and \CFA enumerations. For the first category, the semantics is consistent with C:
 % 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}
+\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}
+%
+\begin{cfa}
+struct S { int i; };
+S ?+?( S & s, one_t ) { return s.i++; }
+void ?{}( S & s, zero_t ) { s.i = 0; }
+enum(S) E { A, B, C, D };
+\end{cfa}
+For \CFA enumeration, the semantics is the following:
+\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 the operator @?+?(T, one_t)@, which 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.
 …
 bar( A );                                                       $\C{// {\color{red}disallowed}}$
 \end{cfa}
 Hence, @Letter@ enumerators are not type compatible with the @Greek@ enumeration but the reverse is true.
+Hence, @Letter@ enumerators are not type-compatible with the @Greek@ enumeration, but the reverse is true.
 …
 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.
+However, the uniqueness of the enumeration name applies to enumerators, including those from supertypes, meaning an enumeration cannot name an enumerator with the same label as its subtype's members or inherits
+from multiple enumeration that has overlapping enumerator labels. Consequently, a new type cannot inherit from 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@ is auto initialized.
+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}
 …
 The algorithm takes two @CFAEnums@ parameters, @src@ and @dst@, with @src@ being the type of expression the conversion applies to, and @dst@ being the type the expression is cast to.
 The algorithm iterates over the members in @dst@ to find @src@.
 If a member is an enumerator of @dst@, the positions of all subsequent members is increment by one.
+If a member is an enumerator of @dst@, the positions of all subsequent members are incremented by one.
 If the current member is @dst@, the function returns true indicating \emph{found} and the accumulated offset.
 Otherwise, the algorithm recurses into the current @CFAEnum@ @m@ to check if its @src@ is convertible to @m@.
 …
 \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 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.
+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 string constants can be quoted or unquoted.
 \begin{figure}

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

Context Navigation

Changeset 7568e5c for doc/theses/jiada_liang_MMath/CFAenum.tex

Legend:

doc/theses/jiada_liang_MMath/CFAenum.tex

Download in other formats: