Changeset a57ad8a for doc

Timestamp:

Aug 4, 2024, 12:22:51 PM (3 months ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master

Children:

748877f

Parents:

503c350

Message:

proofread C Enum chapter

File:

• doc/theses/jiada_liang_MMath/CEnum.tex (modified) (5 diffs)

doc/theses/jiada_liang_MMath/CEnum.tex

@@ -1 @@
-\chapter{C Enumeration in CFA}
+\chapter{C Enumeration in \CFA}
 
 \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.
+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.
+
 
 \section{Enumerator Visibility}
@@ -12 +11 @@
 
 In C, unscoped enumerators present a \newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names.
+\begin{cfa}
+enum E1 { First, Second, Third, Fourth };
+enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$
+\end{cfa}
 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.
+Hence, most ambiguities among C enumerators are implicitly resolved by the \CFA type system, possibly without any programmer knowledge of the conflict.
+In addition, C Enum qualification is added, exactly like aggregate field-qualification, to disambiguate.
+\VRef[Figure]{f:EnumeratorVisibility} shows how resolution, qualification, and casting are used to disambiguate situations for enumerations @E1@ and @E2@.
 
 \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{// overload functions with different return types}$
 E2 f() { return Fourth; }
@@ -42 +41 @@
 \end{figure}
 
-\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, \ie it is rare to get an incorrect selection or ambiguity, even among hundreds of overloaded variables and functions.
-Any ambiguity can be resolved using qualification or casting.
-
 
 \section{Enumerator Scoping}
 
-An enumeration can be scoped, using @'!'@, so the enumerator constants are not projected into the enclosing scope.
+A C Enum 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 };
@@ -61 +56 @@
 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}).
+% 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}
 with ( @Week@, @RGB@ ) {                                $\C{// type names}$
@@ -70 +66 @@
 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{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.)
+In \CFA, the conversion is changed to unidirectional: 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 because the conversion cost is set to @infinity@.
 \begin{cfa}
-enum Bird { Pengin, Robin, Eagle };
+enum Bird { Penguin, Robin, Eagle };
 enum Fish { Shark, Salmon, Whale };
 
-int i = Robin; $\C{// Allow, implicitly converts to 1}$ 
-@enum Bird bird = Shark;@ $\C{// Disallow }$ 
-@enum Bird bird = 1;@  $\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}
-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.
+It is now up to the programmer to insert an explicit cast to force the assignment.
 \begin{cfa}
-@enum Bird bird = (Bird) Shark@ 
-@enum Bird bird = (Bird) 1;@ 
+enum Bird bird = @(Bird)@1;
+enum Bird bird = @(Bird)@Shark 
 \end{cfa}
+
+Note, \CC has the same safe restriction~\cite[C.1.5.7.2]{C++} and provides the same workaround cast.
+\begin{description}[parsep=0pt]
+\item[Change:] \CC objects of enumeration type can only be assigned values of the same enumeration type.
+In C, objects of enumeration type can be assigned values of any integral type.
+Example:
+\begin{cfa}
+enum color { red, blue, green };
+color c = 1;                            $\C{// valid C, invalid \CC}$
+\end{cfa}
+\item[Rationale:] The type-safe nature of \CC.
+\item[Effect on original feature:] Deletion of semantically well-defined feature.
+\item[Difficulty of converting:] Syntactic transformation. (The type error produced by the assignment can be
+automatically corrected by applying an explicit cast.)
+\item[How widely used:] Common.
+\end{description}
+
+\begin{comment}
+\begin{description}[parsep=0pt]
+\item[Change:] In \CC, the type of an enumerator is its enumeration.
+In C, the type of an enumerator is @int@.
+Example:
+\begin{cfa}
+enum e { A };
+sizeof(A) == sizeof(int)        $\C{// in C}$
+sizeof(A) == sizeof(e)          $\C{// in \CC}$
+/* and sizeof(int) is not necessary equal to sizeof(e) */
+\end{cfa}
+\item[Rationale:] In \CC, an enumeration is a distinct type.
+\item[Effect on original feature:] Change to semantics of well-defined feature.
+\item[Difficulty of converting:] Semantic transformation.
+\item[How widely used:] Seldom. The only time this affects existing C code is when the size of an enumerator is
+taken. Taking the size of an enumerator is not a common C coding practice.
+\end{description}
+\end{comment}