Changeset c141c09 for doc

Timestamp:

Aug 2, 2024, 12:32:18 AM (5 hours ago)

Author:

JiadaL <j82liang@…>

Branches:

master

Parents:

3a7cd15

Message:

Update

Location:

doc/theses/jiada_liang_MMath

Files:

• CEnum.tex (modified) (4 diffs)
• CFAenum.tex (modified) (4 diffs)

doc/theses/jiada_liang_MMath/CEnum.tex

@@ -1 @@
-\chapter{C Enum in CFA}
+\chapter{C Enumeration in CFA}
 
-\CFA supports C enumeration using the same syntax for backwards compatibility, and the semantics is mostly consistent with C with small difference in terms of typing.
-C style enums in \CFA language are called "C enum".
-\CFA also extends C-Style enumeration by adding a number of new features that bring enumerations inline with other modern programming languages.
+\CFA supports legacy C enumeration using the same syntax for backwards compatibility. 
+C-style Enumeration in \CFA language are called \newterm{C Enumeration} or \newterm{C Enum}.
+The semantics of C Enumeration is mostly consistent with C with more restrictive typing.
+\CFA also extends C Enumeration by adding a number of new features that bring enumerations aligns 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.
@@ -24 +25 @@
 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}$
+E1 f() { return Third; }                                $\C{// overload functions with different return types}$
 E2 f() { return Fourth; }
 void g( E1 e );
@@ -71 +72 @@
 \section{Type Safety}
 
-As in Section~\ref{s:Usage}, C's implicit conversion between enumeration and integral type raises a safety concern.
-\CFA disallows an implicit conversion from integral type to enueration, and conversion between different C enumeration type.
-It loses some degree of its backward compatibility to C, in exchange for type safety.
+As in Section~\ref{s:Usage}, C's implicit bidirectional conversion between enumeration and integral type raises a safety concern.
+In \CFA, the conversion is unidirectional: 
+% disallows an implicit conversion from integral type to enumeration, and conversion between different C enumeration type.
+% It loses some degree of its backward compatibility to C, in exchange for type safety.
+an enumeration can be implicitly converted into an integral type, with an associated @safe@ conversion cost.
+But an integral type cannot be implicitly converted into a C enumeration. (Conversion Cost is Infinity.)
 \begin{cfa}
 enum Bird { Pengin, Robin, Eagle };
@@ -81 +85 @@
 @enum Bird bird = Shark;@ $\C{// Disallow }$ 
 @enum Bird bird = 1;@  $\C{// Disallow }$ 
-
+\end{cfa}
+As a workaround, \CFA allows an explicit cast to an enumeration, turning an integral type to an enumeration that can be used in assignment or function argument, 
+in which case \CFA treats C enuemration as its underlying integral type. In such cases, it is up to user to ensure program correctness.
+\begin{cfa}
 @enum Bird bird = (Bird) Shark@ 
 @enum Bird bird = (Bird) 1;@ 
 \end{cfa}
-As a workaround, \CFA allows explicit cast to an enumeration, turning an integral type to an enumeration that can be used in assignment or function argument, 
-in which case \CFA treats C enuemration as its underlying integral type. In such cases, it is up to user to ensure program correctness.

doc/theses/jiada_liang_MMath/CFAenum.tex

@@ -202 +202 @@
 
 \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).
-Inheritance can be nested, and a \CFA enumeration can inline enumerators from more than one \CFA enumeration, forming a tree-like structure.
-Howver, the uniqueness of enumeration label applies to enumerators 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 both an enumeration and its supertype, or inherit two enumerations with a 
+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. 
 
@@ -227 +227 @@
 \end{cfa}
 
-The enumeration type for the inheriting type must be the same as the inherited type. 
+% The enumeration base for the subtype must be the same as the super type. 
+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.
@@ -254 +255 @@
 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
+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@. 
 
@@ -414 +415 @@
 To support some level of harmonizing in these cases, an array dimension can be defined using an enumerator type, and the enumerators used as subscripts.
 \begin{cfa}
-enum E { A, B, C, N }; // possibly predefined
-float H1[N] = { [A] : 3.4, [B] : 7.1, [C] : 0.01 }; // C
-float H2[@E@] = { [A] : 3.4, [B] : 7.1, [C] : 0.01 }; // CFA
-\end{cfa}
-(Note, C uses the symbol, @'='@ for designator initialization, but \CFA had to change to @':'@ because of problems with tuple syntax.)
+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 H2[@E2@] = { [A] : 3.4, [B] : 7.1, [C] : 0.01 }; // CFA
+\end{cfa}
 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@).
 
 \section{Enumeration I/O}