Context Navigation

-                      r47bd204
+                      re11cdc0
 \end{abstract}
 \section{Background}
+\section{Introduction}
 Naming values is a common practice in mathematics and engineering, e.g., $\pi$, $\tau$ (2$\pi$), $\phi$ (golden ratio), MHz (1E6), etc.
 Naming is also commonly used to represent many other numerical phenomenon, such as days of the week, months of a year, floors of a building (basement), time (noon, New Years).
+Naming is also commonly used to represent many other numerical phenomenon, such as days of the week, months of a year, floors of a building (basement), specific times (noon, New Years).
 Many programming languages capture this important software-engineering capability through a mechanism called an \newterm{enumeration}.
 An enumeration is similar to other programming-language types by providing a set of constrained values, but adds the ability to name \emph{all} the values in its set.
 …
 Specifically, an enumerated type restricts its values to a fixed set of named constants.
+Fundamentally, all types are restricted to a fixed set of values because of the underlying von Neumann architecture, and hence, to a corresponding set of constants, e.g., @3@, @3.5@, @3.5+2.1i@, @'c'@, @"abc"@, etc.
+However, the values for basic types are not named, other than the programming-language supplied constants.
+\section{C-Style Enum}
+The C-Style enumeration has the following syntax and semantics, and is representative of enumerations in many other programming languages (see Section~\ref{s:RelatedWork}).
+\begin{lstlisting}[label=lst:weekday]
+enum Weekday { Monday, Tuesday, Wednesday, Thursday@ = 10@, Friday, Saturday, Sunday };
+                $\(\uparrow\)$                                                                        $\(\uparrow\)$
+    ${\rm \newterm{enumeration name}}$                                          ${\rm \newterm{enumerator names}}
+\end{lstlisting}
+Here, the enumeration type @Weekday@ defines the ordered \newterm{enumerator}s @Monday@, @Tuesday@, @Wednesday@, @Thursday@, @Friday@, @Saturday@ and @Sunday@.
+By convention, the successor of @Tuesday@ is @Monday@ and the predecessor of @Tuesday@ is @Wednesday@, independent of the associated enumerator constants.
+Because an enumerator is a constant, it cannot appear in a mutable context, e.g. @Mon = Sun@ is meaningless, and has no address, it is an rvalue\footnote{
+The term rvalue defines an expression that can only appear on the right-hand side of an assignment.}.
+Enumerators without explicitly designated constants are auto-initialized by the compiler: from left to right, starting at zero or the next explicitly initialized constant, incrementing by @1@.
+For example, @Monday@ to @Wednesday@ are implicitly assigned with constants 0--2, @Thursday@ is explicitly set to constant @10@, and @Friday@ to @Sunday@ are implicitly assigned with constants 11--13.
+Hence, there are 3 universal enumeration attributes: \newterm{position}, \newterm{label}, and \newterm{value}:
+While all types are restricted to a fixed set of values because of the underlying von Neumann architecture, and hence, to a corresponding set of constants, e.g., @3@, @3.5@, @3.5+2.1i@, @'c'@, @"abc"@, etc., these values are not named, other than the programming-language supplied constants.
+Fundamentally, all enumeration systems have an \newterm{enumeration} type with its associated \newterm{enumerator} constants.
+These components have three universal attributes, \newterm{position}, \newterm{label}, and \newterm{value}, as shown by this representative enumeration, where position and value can be different.
 \begin{cquote}
 \small\sf\setlength{\tabcolsep}{3pt}
 \begin{tabular}{rccccccccccc}
+@enum@ Weekday \{       & Monday,       & Tuesday,      & Wednesday,    & Thursday = 10,& Friday,       & Saturday,     & Sunday \}; \\
+\it\color{red}position          & 0                     & 1                     & 2                             & 3                             & 4                     & 5                     & 6                     \\
+\it\color{red}label                     & Monday        & Tuesday       & Wednesday             & Thursday              & Friday        & Saturday      & Sunday        \\
+\it\color{red}value                     & 0                     & 1                     & 2                             & {\color{red}10}& 11           & 12            & 13
+\it\color{red}enumeration & \multicolumn{7}{c}{\it\color{red}enumerators}       \\
+$\downarrow$\hspace*{25pt} & \multicolumn{7}{c}{$\downarrow$}                           \\
+@enum@ Weekday \{                               & Monday,       & Tuesday,      & Wednesday,    & Thursday,& Friday,    & Saturday,     & Sunday \}; \\
+\it\color{red}position                  & 0                     & 1                     & 2                             & 3                             & 4                     & 5                     & 6                     \\
+\it\color{red}label                             & Monday        & Tuesday       & Wednesday             & Thursday              & Friday        & Saturday      & Sunday        \\
+\it\color{red}value                             & 0                     & 1                     & 2                             & 3                             & 4                     & 5             & 6
 \end{tabular}
 \end{cquote}
+Finally, C enumerators are \newterm{unscoped}, i.e., enumerators declared inside of an @enum@ are visible in the enclosing scope of the @enum@ type.
+Here, the \newterm{enumeration} @Weekday@ defines the ordered \newterm{enumerator}s @Monday@, @Tuesday@, @Wednesday@, @Thursday@, @Friday@, @Saturday@ and @Sunday@.
+By convention, the successor of @Tuesday@ is @Monday@ and the predecessor of @Tuesday@ is @Wednesday@, independent of the associated enumerator constant values.
+Because an enumerator is a constant, it cannot appear in a mutable context, e.g. @Mon = Sun@ is meaningless, and an enumerator has no address, it is an \newterm{rvalue}\footnote{
+The term rvalue defines an expression that can only appear on the right-hand side of an assignment.}.
+\section{C-Style Enum}
+The C-Style enumeration has the following syntax and semantics.
+\begin{lstlisting}
+enum Weekday { Monday, Tuesday, Wednesday, Thursday@ = 10@, Friday, Saturday, Sunday };
+\end{lstlisting}
+Enumerators without an explicitly designated constant value are \newterm{auto-initialized} by the compiler: from left to right, starting at zero or the next explicitly initialized constant, incrementing by @1@.
+For example, @Monday@ to @Wednesday@ are implicitly assigned with constants @0@--@2@, @Thursday@ is explicitly set to constant @10@, and @Friday@ to @Sunday@ are implicitly assigned with constants @11@--@13@.
+Initialization may occur in any order.
+\begin{lstlisting}
+enum Weekday { Thursday@ = 10@, Friday, Saturday, Sunday, Monday@ = 0@, Tuesday, Wednesday };
+\end{lstlisting}
+Note, the comma in the enumerator list can be a terminator or a separator, allowing the list to end with a dangling comma.
+\begin{lstlisting}
+enum Weekday {
+        Thursday = 10, Friday, Saturday, Sunday,
+        Monday = 0, Tuesday, Wednesday@,@ // terminating comma
+};
+\end{lstlisting}
+This feature allow enumerator lines to be interchanged without moving a comma.\footnote{
+A terminating comma appears in other C syntax, e.g., the initializer list.}
+Finally, C enumerators are \newterm{unscoped}, i.e., enumerators declared inside of an @enum@ are visible (projected) in the enclosing scope of the @enum@ type.
 In theory, a C enumeration \emph{variable} is an implementation-defined integral type large enough to hold all enumerated values.
 In practice, since integral constants in C have type @int@ (unless qualified with a size suffix), C uses @int@ as the underlying type for enumeration variables.
 Furthermore, there is an implicit bidirectional conversion between an enumeration and integral types.
+In practice, since integral constants are used, which have type @int@ (unless qualified with a size suffix), C uses @int@ as the underlying type for enumeration variables.
+Finally, there is an implicit bidirectional conversion between an enumeration and integral types.
 \begin{lstlisting}[label=lst:enum_scope]
+{
         enum Weekday { ... };                           $\C{// enumerators implicitly projected into local scope}$
+        enum Weekday { /* as above */ };        $\C{// enumerators implicitly projected into local scope}$
         Weekday weekday = Monday;                       $\C{// weekday == 0}$
         weekday = Friday;                                       $\C{// weekday == 11}$
         int i = Sunday                                          $\C{// implicit conversion to int, i == 13}$
+        int i = Sunday;                                         $\C{// implicit conversion to int, i == 13}$
         weekday = 10000;                                        $\C{// UNDEFINED! implicit conversion to Weekday}$
+}
 …
 The implicit conversion from @int@ to an enumeration type is an unnecessary source of error.
+It is common for C programmers to ``believe'' there are 3 equivalent forms of constant enumeration.
+\begin{lstlisting}[label=lst:enum_scope]
+#define Monday 0
+static const int Monday = 0;
+enum { Monday };
+\end{lstlisting}
+For @#define@, the programmer has to play compiler and explicitly manage the enumeration values;
+furthermore, these are independent constants outside of any language type mechanism.
+The same explicit management is true for @const@ declarations, and the @const@ variable cannot appear in constant-expression locations, like @case@ labels, array dimensions,\footnote{
+C allows variable-length array-declarations (VLA), so this case does work, but it fails in \CC, which does not support VLAs, unless it is \lstinline{g++}.} and immediate operands of assembler instructions.
+Only the @enum@ form is managed by the compiler, is part of the language type-system, and works in all C constant-expression locations.
 \section{\CFA-Style Enum}
 …
 \CFA also extends C-Style enumeration by adding a number of new features that bring enumerations inline with other modern programming languages.
+\subsection{Enumerator Name Resolution}
+\label{s:EnumeratorNameResolution}
+In C, unscoping of enumerators presents a \newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names.
+There is no mechanism in C to resolve these naming conflicts other than renaming of one of the duplicates, which may not be possible.
+The \CFA type-system allows extensive overloading, including enumerators.
+Furthermore, \CFA uses the left-hand of assignment in type resolution to pinpoint the best overloaded name.
+Finally, qualification is provided to disambiguate any ambiguous situations.
+\begin{lstlisting}
+enum C1 { First, Second, Third, Fourth };
+enum C2 { @Fourth@, @Third@, @Second@, @First@ };
+C1 p() { return Third; }                                $\C{// correctly resolved duplicate names}$
+C2 p() { return Fourth; }
+void foo() {
+        C1 e1 = First;   C2 e2 = First;
+        e1 = Second;   e2 = Second;
+        e1 = p();   e2 = p();
+        e1 = @C1.@First + @C1.@First;           $\C{// ambiguous without qualification (and dangerous)}$
+}
+\end{lstlisting}
+\CFA overloading allows programmers to use the most meaningful names with little fear of unresolvable clashes from included files, which can always be corrected.
+\subsection{Enumerator Scoping}
+An enumeration can be scoped, so the enumerator constants are not projected into the enclosing scope, using @'!'@.
+\begin{lstlisting}
+enum Weekday @!@ { /* as above */ };
+enum( char * ) Names @!@ { /* as above */ };
+\end{lstlisting}
+Now the enumerators must be qualified with the associated enumeration.
+\begin{lstlisting}
+Weekday weekday = @Weekday@.Monday;
+Names names = @Names.@Fred;
+names = @Names.@Jane;
+\end{lstlisting}
+It is possible to toggle back to unscoping using the \CFA @with@ clause/statement.
+\begin{lstlisting}
+Weekday weekday;
+with ( @Weekday@, @Names@ ) {                   $\C{// type names}$
+         Names names = @Fred@;
+         names = @Jane@;
+         weekday = Saturday;
+}
+\end{lstlisting}
+As in section~\ref{s:EnumeratorNameResolution}, opening multiple unscoped enumerations can result in duplicate enumeration names, but \CFA type resolution and falling back to explicit qualification handles ambiguities.
 \subsection{Enumerator Typing}
+\CFA extends the enumeration by parameterizing the enumeration with a type for the enumerators, allowing enumerators to be assigned any values from the declared 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 constants used to set the enumerators.
+Typed enumerates deals with \emph{harmonizing} problem between an enumeration and its companion data.
+The following example is from the \CFA compiler, written in \CC.
+\begin{lstlisting}
+enum integral_types { chr, schar, uschar, sshort, ushort, sint, usint, ..., NO_OF_ITYPES };
+char * integral_names[NO_OF_ITYPES] = {
+        "char", "signed char", "unsigned char",
+        "signed short int", "unsigned short int",
+        "signed int", "unsigned int",
+        ...
+};
+\end{lstlisting}
+The \emph{harmonizing} problem occurs because the enumeration declaration is in one header file and the names are declared in another translation unit.
+It is up to the programmer to ensure changes made in one location are harmonized with the other location (by identifying this requirement within a comment).
+The typed enumeration largely solves this problem by combining and managing the two data types.
+\begin{lstlisting}
+enum( char * ) integral_types {
+        chr = "char", schar = "signed char", uschar = "unsigned char",
+        sshort = "signed short int", ushort = "unsigned short int",
+        sint = "signed int", usint = "unsigned int",
+        ...
+};
+\end{lstlisting}
+\CFA extends the enumeration declaration by parameterizing with a type (like a generic type), allowing enumerators to be assigned any values from the declared 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 constants used to set the enumerator constants.
+Note, the synonyms @Liz@ and @Beth@ in the last declaration.
 % \begin{lstlisting}[label=lst:color]
 …
         enum( @_Complex@ ) Plane { X = 1.5+3.4i, Y = 7+3i, Z = 0+0.5i };
 // pointer
         enum( @char *@ ) Names { Fred = "Fred", Mary = "Mary", Jane = "Jane" };
+        enum( @char *@ ) Names { Fred = "FRED", Mary = "MARY", Jane = "JANE" };
         int i, j, k;
         enum( @int *@ ) ptr { I = &i,  J = &j,  K = &k };
         enum( @int &@ ) ref { I = i,   J = j,   K = k };
 // tuple
         enum( @[int, int]@ ) { T = [ 1, 2 ] };
+        enum( @[int, int]@ ) { T = [ 1, 2 ] }; $\C{// new \CFA type}$
 // function
         void f() {...}   void g() {...}
 …
 // aggregate
         struct Person { char * name; int age, height; };
         enum( @Person@ ) friends { Liz = { "Elizabeth", 22, 170 }, Beth = Liz, Jon = { "Jonathan", 35, 190 } };
+@***@enum( @Person@ ) friends { @Liz@ = { "ELIZABETH", 22, 170 }, @Beth@ = Liz, Jon = { "JONATHAN", 35, 190 } };
 \end{lstlisting}
 \caption{Enumerator Typing}
 …
 \end{figure}
+Typed enumerations deals with the \emph{harmonizing} problem between an enumeration and any companion data.
+The following example is from the \CFA compiler, written in \CC.
+\begin{lstlisting}
+enum integral_types { chr, schar, uschar, sshort, ushort, sint, usint, ..., NO_OF_ITYPES };
+char * integral_names[NO_OF_ITYPES] = {
+        "char", "signed char", "unsigned char",
+        "signed short int", "unsigned short int",
+        "signed int", "unsigned int",
+        ...
+};
+\end{lstlisting}
+The \emph{harmonizing} problem occurs because the enumeration declaration is in one header file and the names are declared in another translation unit.
+It is up to the programmer to ensure changes made in one location are harmonized with the other location (by identifying this requirement within a comment).
+The typed enumeration largely solves this problem by combining and managing the two data types.
+\begin{lstlisting}
+enum( char * ) integral_types {
+        chr = "char", schar = "signed char", uschar = "unsigned char",
+        sshort = "signed short int", ushort = "unsigned short int",
+        sint = "signed int", usint = "unsigned int",
+        ...
+};
+\end{lstlisting}
 \subsection{Pure Enumerators}
 …
 \begin{lstlisting}
 enum() Mode { O_RDONLY, O_WRONLY, O_CREAT, O_TRUNC, O_APPEND };
 Mode iomode = O_RDONLY;
+@***@Mode iomode = O_RDONLY;
 int i = iomode;                                                 $\C{\color{red}// disallowed}$
-sout | O_TRUNC;                                                 $\C{\color{red}// disallowed}$
 \end{lstlisting}
 \subsection{Enumerator Subset}
 If follows from enumerator typing that the type of the enumerators can be another enumerator.
+If follows from enumerator typing that the enumerator type can be another enumerator.
 \begin{lstlisting}
 enum( char ) Letter { A = 'A',  B = 'B', C = 'C', ..., Z = 'Z' };
+enum( Letter ) Greek { Alph = A, Beta = B, ..., Zeta = Z }; // alphabet intersection
+Letter letter = A;
+Greak greek = Alph;
+letter = Alph;                                                  $\C{// allowed}$
+greek = A;                                                              $\C{\color{red}// disallowed}$
+enum( @Letter@ ) Greek { Alph = A, Beta = B, ..., Zeta = Z }; // alphabet intersection
 \end{lstlisting}
 Enumeration @Greek@ may have more or less enumerators than @Letter@, but the enumerator values must be from @Letter@.
 Therefore, @Greek@ enumerators are a subset of type @Letter@ and are type compatible with enumeration @Letter@, but @Letter@ enumerators are not type compatible with enumeration @Greek@.
+\begin{lstlisting}
+Letter letter = A;
+@***@Greak greek = Beta;
+letter = Beta;                                                  $\C{// allowed, letter == B}$
+greek = A;                                                              $\C{\color{red}// disallowed}$
+\end{lstlisting}
 \subsection{Enumeration Inheritance}
 …
 \CFA Plan-9 inheritance may be used with enumerations.
 \begin{lstlisting}
+enum( char * ) Name2 { @inline Name@, Jack = "Jack", Jill = "Jill" };
+enum /* inferred */ Name3 { @inline Name2@, Sue = "Sue", Tom = "Tom" };
+\end{lstlisting}
+Enumeration @Name2@ inherits all the enumerators and their values from enumeration @Name@ by containment, and a @Name@ enumeration is a subtype of enumeration @Name2@.
+enum( char * ) Names { /* as above */ };
+enum( char * ) Names2 { @inline Names@, Jack = "JACK", Jill = "JILL" };
+@***@enum /* inferred */ Names3 { @inline Names2@, Sue = "SUE", Tom = "TOM" };
+\end{lstlisting}
+Enumeration @Name2@ inherits all the enumerators and their values from enumeration @Names@ by containment, and a @Names@ enumeration is a subtype of enumeration @Name2@.
 Note, enumerators must be unique in inheritance but enumerator values may be repeated.
 The enumeration type for the inheriting type must be the same as the inherited type;
 hence the enumeration type may be omitted for the inheriting enumeration and it is inferred from the inherited enumeration, as for @Name3@.
+When inheriting from integral types, automatic numbering may be used, so the inheritance placement left to right is important.
+Specifically, the inheritance relationship for Names is:
+\begin{lstlisting}
+Name $\(\subset\)$ Name2 $\(\subset\)$ Name3 $\(\subset\)$ const char *         // enum type of Name
+% When inheriting from integral types, automatic numbering may be used, so the inheritance placement left to right is important.
+Specifically, the inheritance relationship for @Names@ is:
+\begin{lstlisting}
+Names $\(\subset\)$ Names2 $\(\subset\)$ Names3 $\(\subset\)$ const char * $\C{// enum type of Names}$
 \end{lstlisting}
 For the given function prototypes, the following calls are valid.
 …
 \begin{tabular}{ll}
 \begin{lstlisting}
 void f( Name );
 void g( Name2 );
 void h( Name3 );
+void f( Names );
+void g( Names2 );
+void h( Names3 );
 void j( const char * );
 \end{lstlisting}
 …
 g( Fred );   g( Jill );
 h( Fred );   h( Jill );   h( Sue );
 j( Fred );   j( Jill );   j( Sue );   j( "Will" );
+j( Fred );   j( Jill );   j( Sue );   j( "WILL" );
 \end{lstlisting}
 \end{tabular}
 …
 Note, the validity of calls is the same for call-by-reference as for call-by-value, and const restrictions are the same as for other types.
-\subsection{Enumerator Scoping}
-A \CFA-enum can be scoped, meaning the enumerator constants are not projected into the enclosing scope.
-\begin{lstlisting}
-enum Weekday @!@ { /* as above */ };
-enum Colour( char * ) @!@ { /* as above */ };
-\end{lstlisting}
-where the @'!'@ implies the enumerators are \emph{not} projected.
-The enumerators of a scoped enumeration are accessed using qualifications, like the fields of an aggregate.
-% The syntax of $qualified\_expression$ for \CFA-enum is the following:
-% $$<qualified\_expression> := <enum\_type>.<enumerator>$$
-\begin{lstlisting}
-Weekday weekday = @Weekday.Monday@;             $\C{// qualification}$
-Colour colour = @Colour.@Red;
-colour = @Colour.@Blue;
-\end{lstlisting}
 \subsection{Enumeration Pseudo-functions}
 …
 Often a call to a pseudo-function is substituted with information extracted from the symbol table at compilation time, like storage size or alignment associated with the underlying architecture..
 \subsubsection{Enumerator Attributes}
 The attributes of an enumerator are accessed by pseudo-functions @position@, @value@, and @label@.
 \begin{lstlisting}
+int green_pos = @position@( Colour.Green );     $\C{// 1}$
+char * green_value = @value@( Colour.Green ); $\C{// "G"}$
+char * green_label = @label@( Colour.Green ); $\C{// "Green"}$
+\end{lstlisting}
+Enumeration Greek may have more or less enumerators than Letter, but the enumerator values must be from Letter.
+Therefore, Greek enumerators are a subset of type Letter and are type compatible with enumeration Letter, but Letter enumerators are not type compatible with enumeration Greek.
+@***@int jane_pos = position( Names.Jane );   $\C{// 2}$
+@***@char * jane_value = value( Names.Jane ); $\C{// "JANE"}$
+@***@char * jane_label = label( Names.Jane ); $\C{// "Jane"}$
+\end{lstlisting}
 % An instance of \CFA-enum (denoted as @<enum_instance>@) is a label for the defined enum name.
 …
 % Similarly, the @value()@ function returns the value used to initialize the \CFA-enum.
+\subsubsection{\lstinline{enumerate()}}
+\begin{lstlisting}[label=lst:c_switch]
+enum(int) C_ENUM { First, Second, Third = First, Fourth };
+int v( C_ENUM e ) {
+        switch( e ) {
+                case First: return 0; break;
+                case Second: return 1; break;
+                // case Third: return 2; break;
+                // case Fourth: return 3; break;
+        };
+};
+\end{lstlisting}
+In the @C_ENUM@ example, @Third@ is an alias of @First@ and @Fourth@ is an alias of @Second@.
+Programmers cannot make case branches for @Third@ and @Fourth@ because the switch statement matches cases by the enumerator's value.
+Case @First@ and @Third@, or @Second@ and @Fourth@, has duplicate case values.
+@enumerate()@ is a pseudo-function that makes the switch statement match by an enumerator instead.
+\begin{lstlisting}[label=lst:c_switch_enumerate]
+enum(double) C_ENUM { First, Second, Third = First, Fourth };
+C_ENUM variable_a = First, variable_b = Second, variable_c = Third, variable_d = Fourth;
+int v(C_ENUM e) {
+        switch( enumeratate( e ) ) {
+                case First: return e; break;
+                case Second: return value( e ); break;
+                case Third: return label( e ); break;
+                case Fourth: return position( e ); break;
+        };
+};
+\subsubsection{\lstinline{switch/choose} Statement}
+An intuitive use of enumerations is with the \CFA @switch@/@choose@ statement, where @choose@ performs an implict @break@ rather than a fall-through at the end of a @case@ clause.
+\begin{lstlisting}
+enum Count { First, Second, Third, Fourth };
+Count e;
+\end{lstlisting}
+\begin{cquote}
+\begin{tabular}{ll}
+\begin{lstlisting}
+choose( e ) {
+        case @First@: ...;
+        case @Second@: ...;
+        case @Third@: ...;
+        case @Fourth@: ...;
+}
+\end{lstlisting}
+&
+\begin{lstlisting}
+choose( @value@( e ) ) {
+        case @value@( First ): ...;
+        case @value@( Second ): ...;
+        case @value@( Third ): ...;
+        case @value@( Fourth ): ...;
+}
+\end{lstlisting}
+\end{tabular}
+\end{cquote}
+Here, the intuitive implementation on the right uses the value of the enumeration and enumerators.
+However, this implementation is fragile, e.g., if the enumeration is changed to:
+\begin{lstlisting}
+enum Count { First, Second, Third @= First@, Fourth };
+\end{lstlisting}
+which make @Third == First@ and @Fourth == Second@, causing duplicase @case@ clauses.
+To better match with programmer intuition, \CFA uses a more robust implementation form when the type of a @switch@ expression is an enumeration.
+\begin{lstlisting}
+choose( @position@( e ) ) {
+        case @position@( First ): ...;
+        case @position@( Second ): ...;
+        case @position@( Third ): ...;
+        case @position@( Fourth ): ...;
+}
+\end{lstlisting}
+\begin{lstlisting}
+Count variable_a = First, variable_b = Second, variable_c = Third, variable_d = Fourth;
 p(variable_a); // 0
 p(variable_b); // 1
 …
 If the @aggregation_name@ is identified as a \CFA enumeration, the compiler checks if @field@ presents in the declared \CFA enumeration.
-\subsection{\lstinline{with} Clause/Statement}
-Instead of qualifying an enumeration expression every time, the @with@ can be used to expose enumerators to the current scope, making them directly accessible.
-\begin{lstlisting}[label=lst:declaration]
-enum Color( char * ) { Red="R", Green="G", Blue="B" };
-enum Animal( int ) { Cat=10, Dog=20 };
-with ( Color, Animal ) {
-        char * red_string = Red; // value( Color.Red )
-        int cat = Cat; // value( Animal.Cat )
+}
-\end{lstlisting}
-The \lstinline{with} might introduce ambiguity to a scope. Consider the example:
-\begin{lstlisting}[label=lst:declaration]
-enum Color( char * ) { Red="R", Green="G", Blue="B" };
-enum RGB( int ) { Red=0, Green=1, Blue=2 };
-with ( Color, RGB ) {
-        // int red = Red;
+}
-\end{lstlisting}
-\CFA will not try to resolve the expression with ambiguity. It would report an error. In this case, it is necessary to qualify @Red@ even inside of the \lstinline{with} clause.
 \subsection{Instance Declaration}

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

Context Navigation

Changeset e11cdc0 for doc/proposals

Legend:

doc/proposals/enum.tex

Download in other formats: