source: doc/theses/jiada_liang_MMath/CEnum.tex @ c141c09

Last change on this file since c141c09 was c141c09, checked in by JiadaL <j82liang@…>, 3 months ago

Update

  • Property mode set to 100644
File size: 5.3 KB
Line 
1\chapter{C Enumeration in CFA}
2
3\CFA supports legacy C enumeration using the same syntax for backwards compatibility.
4C-style Enumeration in \CFA language are called \newterm{C Enumeration} or \newterm{C Enum}.
5The semantics of C Enumeration is mostly consistent with C with more restrictive typing.
6\CFA also extends C Enumeration by adding a number of new features that bring enumerations aligns with other modern programming languages.
7Any enumeration extensions must be intuitive to C programmers both in syntax and semantics.
8The following sections detail all of my new contributions to enumerations in \CFA.
9
10\section{Enumerator Visibility}
11\label{s:EnumeratorVisibility}
12
13In C, unscoped enumerators present a \newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names.
14There 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.
15
16The \CFA type-system allows extensive overloading, including enumerators.
17Furthermore, \CFA uses the environment, such as the left-hand of assignment and function arguments, to pinpoint the best overloaded name.
18\VRef[Figure]{f:EnumeratorVisibility} shows enumeration overloading and how qualification and casting are used to disambiguate ambiguous situations.
19\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.
20Experience from \CFA developers is that the type system implicitly and correctly disambiguates the majority of overloaded names.
21That 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.
22
23\begin{figure}
24\begin{cfa}
25enum E1 { First, Second, Third, Fourth };
26enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$
27E1 f() { return Third; }                                $\C{// overload functions with different return types}$
28E2 f() { return Fourth; }
29void g( E1 e );
30void h( E2 e );
31void foo() {                                                    $\C{// different resolutions and dealing with ambiguities}$
32        E1 e1 = First;   E2 e2 = First;         $\C{// initialization}$
33        e1 = Second;   e2 = Second;                     $\C{// assignment}$
34        e1 = f();   e2 = f();                           $\C{// function return}$
35        g( First );   h( First );                       $\C{// function argument}$
36        int i = @E1.@First + @E2.@First;        $\C{// disambiguate with qualification}$
37        int j = @(E1)@First + @(E2)@First;      $\C{// disambiguate with cast}$
38}
39\end{cfa}
40\caption{Enumerator Visibility and Disambiguating}
41\label{f:EnumeratorVisibility}
42\end{figure}
43
44\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.
45Experience 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.
46Any ambiguity can be resolved using qualification or casting.
47
48
49\section{Enumerator Scoping}
50
51An enumeration can be scoped, using @'!'@, so the enumerator constants are not projected into the enclosing scope.
52\begin{cfa}
53enum Week @!@ { Mon, Tue, Wed, Thu = 10, Fri, Sat, Sun };
54enum RGB @!@ { Red, Green, Blue };
55\end{cfa}
56Now the enumerators \emph{must} be qualified with the associated enumeration type.
57\begin{cfa}
58Week week = @Week.@Mon;
59week = @Week.@Sat;
60RGB rgb = @RGB.@Red;
61rgb = @RGB.@Blue;
62\end{cfa}
63{\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}).
64\begin{cfa}
65with ( @Week@, @RGB@ ) {                                $\C{// type names}$
66         week = @Sun@;                                          $\C{// no qualification}$
67         rgb = @Green@;
68}
69\end{cfa}
70As 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.
71
72\section{Type Safety}
73
74As in Section~\ref{s:Usage}, C's implicit bidirectional conversion between enumeration and integral type raises a safety concern.
75In \CFA, the conversion is unidirectional:
76% disallows an implicit conversion from integral type to enumeration, and conversion between different C enumeration type.
77% It loses some degree of its backward compatibility to C, in exchange for type safety.
78an enumeration can be implicitly converted into an integral type, with an associated @safe@ conversion cost.
79But an integral type cannot be implicitly converted into a C enumeration. (Conversion Cost is Infinity.)
80\begin{cfa}
81enum Bird { Pengin, Robin, Eagle };
82enum Fish { Shark, Salmon, Whale };
83
84int i = Robin; $\C{// Allow, implicitly converts to 1}$ 
85@enum Bird bird = Shark;@ $\C{// Disallow }$ 
86@enum Bird bird = 1;@  $\C{// Disallow }$ 
87\end{cfa}
88As 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,
89in which case \CFA treats C enuemration as its underlying integral type. In such cases, it is up to user to ensure program correctness.
90\begin{cfa}
91@enum Bird bird = (Bird) Shark@
92@enum Bird bird = (Bird) 1;@
93\end{cfa}
Note: See TracBrowser for help on using the repository browser.