Index: doc/proposals/enum.tex =================================================================== --- doc/proposals/enum.tex (revision bd674421bdcbbd7f54eef5135c34f20906db12b0) +++ doc/proposals/enum.tex (revision e11cdc0a5ff47ae542d05ae7f3c78c0d944761df) @@ -117,8 +117,8 @@ \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. @@ -126,43 +126,57 @@ 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}$ } @@ -171,4 +185,17 @@ 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} @@ -176,31 +203,59 @@ \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] @@ -223,10 +278,10 @@ 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() {...} @@ -234,5 +289,5 @@ // 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} @@ -240,4 +295,27 @@ \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} @@ -247,22 +325,24 @@ \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} @@ -270,17 +350,17 @@ \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. @@ -288,7 +368,7 @@ \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} @@ -298,5 +378,5 @@ 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} @@ -304,20 +384,4 @@ 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: -% $$ := .$$ -\begin{lstlisting} -Weekday weekday = @Weekday.Monday@; $\C{// qualification}$ -Colour colour = @Colour.@Red; -colour = @Colour.@Blue; -\end{lstlisting} \subsection{Enumeration Pseudo-functions} @@ -326,14 +390,12 @@ 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 @@) is a label for the defined enum name. @@ -341,33 +403,51 @@ % 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 @@ -1015,25 +1095,4 @@ 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}