Ignore:
Timestamp:
Nov 13, 2023, 10:03:02 AM (7 months ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
master
Children:
0bd3faf
Parents:
fc12f05
Message:

latex formatting changes

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/proposals/enum.tex

    rfc12f05 r25f2798  
    1515\renewcommand\subparagraph{\@startsection{subparagraph}{4}{\z@}{-1.5ex \@plus -1ex \@minus -.2ex}{-1em}{\normalfont\normalsize\bfseries\itshape}}
    1616\makeatother
     17
     18\usepackage[ignoredisplayed]{enumitem}  % do not affect trivlist
     19\setlist{labelsep=1ex}% global
     20\setlist[itemize]{topsep=0.5ex,parsep=0.25ex,itemsep=0.25ex,listparindent=\parindent,leftmargin=\parindent}% global
     21\setlist[itemize,1]{label=\textbullet}% local
     22%\renewcommand{\labelitemi}{{\raisebox{0.25ex}{\footnotesize$\bullet$}}}
     23\setlist[enumerate]{topsep=0.5ex,parsep=0.25ex,itemsep=0.25ex,listparindent=\parindent}% global
     24\setlist[enumerate,2]{leftmargin=\parindent,labelsep=*,align=parleft,label=\alph*.}% local
     25\setlist[description]{topsep=0.5ex,itemsep=0pt,listparindent=\parindent,leftmargin=\parindent,labelsep=1.5ex}
    1726
    1827\newenvironment{cquote}{%
     
    124133% Similarly, the @value()@ function returns the value used to initialize the \CFA-enum.
    125134
    126 A \CFA-enum is scoped: enumeration constants are not automatically exposed to the global scope. Enumeration constant can be referenced using qualified expressions like an aggregate that supports qualified references to its fields. The syntax of $qualified_expression$ for \CFA-enum is the following:
     135A \CFA-enum is scoped: enumeration constants are not automatically exposed to the global scope.
     136Enumeration constant can be referenced using qualified expressions like an aggregate that supports qualified references to its fields. The syntax of $qualified\_expression$ for \CFA-enum is the following:
    127137$$<qualified\_expression> := <enum\_type>.<enumerator>$$
    128138
     
    132142Colour green = Colour.Green;
    133143\end{lstlisting}
    134 The ~\ref{lst:sample_cforall_enum_usage} example declares a $enumeration\ instance$ named \textit{red} and initializes it with $enumeration\ constant$ \textit{Color.Red}. An enumeration instance is a data structure that captures attributes of an enumeration constant, which can be retrieved by functions $position( enumeration\ instance )$, $value( enumeration\ instance )$, and $label( enumeration\ instance )$.
    135 
     144The ~\ref{lst:sample_cforall_enum_usage} example declares a $enumeration\ instance$ named @red@ and initializes it with $enumeration\ constant$ @Color.Red@.
     145An enumeration instance is a data structure that captures attributes of an enumeration constant, which can be retrieved by functions $position( enumeration\ instance )$, $value( enumeration\ instance )$, and $label( enumeration\ instance )$.
    136146\begin{lstlisting}
    137147int green_pos = position( green ); // 1
     
    139149char * green_label = label( green ); // "Green"
    140150\end{lstlisting}
    141 
    142151An enumeration instance can be assigned to a variable or used as its position with type integer, its value with declared type T, or its label with type char *, and the compiler will resolve the usage as a type fits the context.
    143 
    144152\begin{lstlisting}[label=lst:enum_inst_assign_int]
    145153int green_pos = green; // equivalent to position( green );
    146154\end{lstlisting}
    147 
    148 A resolution of an enumeration constant is $unambigious$ if only one of the attributes has the resolvable type. In the example~\ref{lst:enum_inst_assign_int }, the right-hand side of the assignment expression expects integer type. The position of an enumeration is int, while the other two cannot be resolved as integers. The expression unambiguously returns the position of green.
    149 
     155A resolution of an enumeration constant is $unambigious$ if only one of the attributes has the resolvable type.
     156In example~\ref{lst:enum_inst_assign_int}, the right-hand side of the assignment expression expects integer type.
     157The position of an enumeration is @int@, while the other two cannot be resolved as integers.
     158The expression unambiguously returns the position of @green@.
    150159\begin{lstlisting}[label=lst:enum_inst_assign_string]
    151160char * green_value = green; // equivalent to value( green );
    152161\end{lstlisting}
    153 On the other hand, the resolution of an enumeration constant is $ambigious$ if multiple attributes have the expected type. In the example~\ref{lst:enum_inst_assign_string}, both value and label have the expected type char *. When a resolution is ambiguous, a \textit{resolution precedence} applies:
    154 $$value > position > label$$
     162On the other hand, the resolution of an enumeration constant is $ambigious$ if multiple attributes have the expected type.
     163In example~\ref{lst:enum_inst_assign_string}, both value and label have the expected type @char *@.
     164When a resolution is ambiguous, a \textit{resolution precedence} applies: $$value > position > label$$
    155165\CFA uses resolution distance to describe if one type can be used as another. While \CFA calculates the resolution distance between the expected type and types of all three attributes, it would not choose the attribute with the closest distance. Instead, when resolving an enumeration constant, \CFA always chooses value whenever it is a possible resolution (resolution distance is not infinite), followed by position, then label.
    156 
    157166\begin{lstlisting}[label=lst:enum_inst_precedence]
    158167enum(double) Foo { Bar };
     
    161170In the example~\ref{lst:enum_inst_precedence}, while $position( Bar )$ has the closest resolution among the three attributes, $Foo.Bar$ is resolved as $value( Bar )$ because of the resolution precedence.
    162171
    163 Although \CFA enumeration captures three different attributes, an instance of enumeration does not occupy extra memory. The $sizeof$ \CFA enumeration instance is always 4 bytes, the same amount of memory to store a C enumeration instance. It comes from the fact that: 1. a \CFA enumeration is always statically typed; 2. it is always resolved as one of its attributes in terms of real usage.
    164 
    165 When creating the enumeration instance green and assigns it with the enumeration constant $Color.Green$, the compilers essentially allocate an integer variables and store the position 1. The invocations of $positions()$, $value()$, and $label()$ turn into calls to special functions defined in the prelude:
     172Although \CFA enumeration captures three different attributes, an instance of enumeration does not occupy extra memory.
     173The @sizeof@ \CFA enumeration instance is always 4 bytes, the same amount of memory to store a C enumeration instance.
     174It comes from the fact that:
     175\begin{enumerate}
     176\item
     177a \CFA enumeration is always statically typed;
     178\item
     179it is always resolved as one of its attributes in terms of real usage.
     180\end{enumerate}
     181When creating the enumeration instance green and assigns it with the enumeration constant @Color.Green@, the compilers essentially allocate an integer variables and store the position 1.
     182The invocations of $positions()$, $value()$, and $label()$ turn into calls to special functions defined in the prelude:
    166183\begin{lstlisting}[label=lst:companion_call]
    167184position( green );
     
    172189>>> label( Colour, 1) -> char *
    173190\end{lstlisting}
    174 T represents the type declared in the \CFA enumeration defined and char * in the example.
     191@T@ represents the type declared in the \CFA enumeration defined and @char *@ in the example.
    175192These generated functions are $Companion Functions$, they take an $companion$ object and the position as parameters.
    176193
    177194\subsection{Companion Object and Companion Function}
     195
    178196\begin{lstlisting}[caption={Enum Type Functions}, label=lst:cforall_enum_functions]
    179197forall( T )  {
     
    181199                const T * const values;
    182200                const char** const labels;
    183             int length;
     201                        int length;
    184202        };
    185203}
    186204\end{lstlisting}
    187 \CFA creates an object of Companion for every \CFA-enumeration. A companion object has the same name as the enumeration is defined for. A companion object stores values and labels of enumeration constants, in the order of the constants defined in the enumeration.
    188 
    189 \CFA generates the definition of companion functions. Because \CFA implicitly stores enumeration instance as its position, the companion function $position$ does nothing but returns the position it passes it. Companions function $value$ and $label$ return the array item at the given position of $values$ and $labels$, respectively.
    190 
     205\CFA creates an object of Companion for every \CFA-enumeration. A companion object has the same name as the enumeration is defined for.
     206A companion object stores values and labels of enumeration constants, in the order of the constants defined in the enumeration.
     207
     208\CFA generates the definition of companion functions. Because \CFA implicitly stores enumeration instance as its position, the companion function $position$ does nothing but returns the position it passes it.
     209Companions function $value$ and $label$ return the array item at the given position of $values$ and $labels$, respectively.
    191210\begin{lstlisting}[label=lst:companion_definition]
    192211int position( Companion o, int pos ) { return pos; }
     
    194213char * label( Companion o, int pos ) { return o.labels[ pos ]; }
    195214\end{lstlisting}
    196 
    197 Notably, the Companion structure definition, and all companion objects, are visible to the users. A user can retrieve values and labels defined in an enumeration by accessing the values and labels directly, or indirectly by calling Companion functions $values$ and $labels$
     215Notably, the Companion structure definition, and all companion objects, are visible to the users.
     216A user can retrieve values and labels defined in an enumeration by accessing the values and labels directly, or indirectly by calling Companion functions $values$ and $labels$
    198217\begin{lstlisting}[label=lst:companion_definition_values_labels]
    199218Colour.values; // read the Companion's values
     
    202221
    203222\subsection{User Define Enumeration Functions}
     223
    204224The Companion objects make extending features for \CFA enumeration easy.
    205225
    206226\begin{lstlisting}[label=lst:companion_user_definition]
    207227char * charastic_string( Companion o, int position ) {
    208     return sprintf("Label: %s; Value: %s", label( o, position ), value( o, position) );
     228        return sprintf("Label: %s; Value: %s", label( o, position ), value( o, position) );
    209229}
    210230printf( charactic_string ( Color, 1 ) );
     
    213233Defining a function takes a Companion object effectively defines functions for all \CFA enumeration.
    214234
    215 The \CFA compiler turns a function call that takes an enumeration instance as a parameter into a function call with a companion object plus a position. Therefore, a user can use the syntax with a user-defined enumeration function call:
     235The \CFA compiler turns a function call that takes an enumeration instance as a parameter into a function call with a companion object plus a position.
     236Therefore, a user can use the syntax with a user-defined enumeration function call:
    216237\begin{lstlisting}[label=lst:companion_user_definition]
    217238charactic_string ( Color.Green ); // equivalent to charactic_string ( Color, 1 )
    218239>>> Label: G; Value: G
    219240\end{lstlisting}
    220 
    221241Similarly, the user can work with the enumeration type itself: (see section ref...)
    222242\begin{lstlisting}[ label=lst:companion_user_definition]
    223243void print_enumerators ( Companion o ) {
    224     for ( c : Companion o ) {
    225         sout | label (c) | value( c ) ;
    226     }
     244        for ( c : Companion o ) {
     245                sout | label (c) | value( c ) ;
     246        }
    227247}
    228248print_enumerators( Colour );
     
    230250
    231251\subsection{Runtime Enumeration}
     252
    232253The Companion structure definition is visible to users, and users can create an instance of Companion object themselves, which effectively constructs a \textit{Runtime Enumeration}.
    233254\begin{lstlisting}[ label=lst:runtime_enum ]
     
    244265\begin{lstlisting}[ label=lst:runtime_enum_usage ]
    245266MyEnum e = MyEnum.First; // Does not work: cannot create an enumeration instance e,
    246                         // and MyEnum.First is not recognizable
     267                                    // and MyEnum.First is not recognizable
    247268\end{lstlisting}
    248269During the compilation, \CFA adds enumeration declarations to an enumeration symbol table and creates specialized function definitions for \CFA enumeration. \CFA does not recognize runtime enumeration during compilation and would not add them to the enumeration symbol table, resulting in a lack of supports for runtime enumeration.
    249270
    250271\section{Enumeration Features}
     272
    251273A trait is a collection of constraints in \CFA, which can be used to describe types.
    252274The \CFA standard library defines traits to categorize types with related enumeration features.
    253275
    254 
    255276\subsection{Auto Initializable}
    256277\label{s:AutoInitializable}
     278
    257279TODO: make the initialization rule a separate section.
    258280
    259 If no explicit initializer is given to an enumeration constant, C initializes the first enumeration constant with value 0, and the other enumeration constant has a value equal to its $predecessor+1$. \CFA enumerations have the same rule in enumeration constant initialization. However, not all types can be automatically initialized by \CFA because the meaning of $zero$, $one$, and addition operator may not be well-defined.
    260 
    261 A type is auto-initializable if it has defined $zero\_t$, $one\_t$, and an addition operator.
     281If no explicit initializer is given to an enumeration constant, C initializes the first enumeration constant with value 0, and the other enumeration constant has a value equal to its $predecessor+1$.
     282\CFA enumerations have the same rule in enumeration constant initialization.
     283However, not all types can be automatically initialized by \CFA because the meaning of $zero$, $one$, and addition operator may not be well-defined.
     284
     285A type is auto-Initializable if it has defined @zero_t@, @one_t@, and an addition operator.
    262286\begin{lstlisting}
    263287forall(T)
     
    268292};
    269293\end{lstlisting}
    270 
    271294An example of user-defined @AutoInitializable@ would look like the following:
    272 \begin{lstlisting}[label=lst:sample_auto_initializable]
     295\begin{lstlisting}[label=lst:sample_auto_Initializable]
    273296struct Odd { int i; };
    274297void ?()( Odd & t, zero_t ) { t.i = 1; };
    275298void ?()( Odd & t, one_t ) { t.i = 2; };
    276299Odd ?+?( Odd t1, Odd t2 )
    277     { return Odd( t1.i + t2.i); };
    278 \end{lstlisting}
    279 
     300        { return Odd( t1.i + t2.i); };
     301\end{lstlisting}
    280302When an enumeration declares an AutoInitializable as its type, no explicit initialization is necessary.
    281 \begin{lstlisting}[label=lst:sample_auto_initializable_usage]
     303\begin{lstlisting}[label=lst:sample_auto_Initializable_usage]
    282304enum AutoInitUsage(Odd) {
    283     A, B, C = 6, D
    284 };
    285 \end{lstlisting}
    286 
    287 In the example~\ref{lst:sample_auto_initializable_usage}, because no initializer is specified for the first enumeration constant @A@, \CFA initializes it with the value of $zero_t$, which is 1. B and D have the values of their $predecessor + one_t$, while $one_t$ has the value 2. Therefore, the enumeration is initialized as the following:
    288 
    289 \begin{lstlisting}[label=lst:sample_auto_initializable_usage_gen]
     305        A, B, C = 6, D
     306};
     307\end{lstlisting}
     308
     309In the example~\ref{lst:sample_auto_Initializable_usage_gen}, because no initializer is specified for the first enumeration constant @A@, \CFA initializes it with the value of @zero_t@, which is 1.
     310@B@ and @D@ have the values of their $predecessor + one_t$, while @one_t@ has the value 2.
     311Therefore, the enumeration is initialized as the following:
     312\begin{lstlisting}[label=lst:sample_auto_Initializable_usage_gen]
    290313enum AutoInitUsage(Odd) {
    291     A=1, B=3, C = 6, D=8
    292 };
    293 \end{lstlisting}
    294 
     314        A=1, B=3, C = 6, D=8
     315};
     316\end{lstlisting}
    295317In \CFA, integral types, float types, and imaginary numbers are example types that are AutoInitialiable.
    296318\begin{lstlisting}[label=lst:letter]
    297319enum Alphabet(int) {
    298     A='A', B, C, D, E, F, G, H, I, J, K, L, M,
    299     N, O, P, Q, R, S, T, U, V, W, X, Y, Z,
    300     a='a', b, c, d, e, f, g, h, i, j, k, l, m,
    301     n, o, p, q, r, s, t, u, v, w, x, y, z
     320        A='A', B, C, D, E, F, G, H, I, J, K, L, M,
     321        N, O, P, Q, R, S, T, U, V, W, X, Y, Z,
     322        a='a', b, c, d, e, f, g, h, i, j, k, l, m,
     323        n, o, p, q, r, s, t, u, v, w, x, y, z
    302324};
    303325print( "%c, %c, %c", Alphabet.F, Alphabet.o, Alphabet.o );
     
    307329\subsection{Iteration and Range}
    308330
    309 It is convenient to iterate over a \CFA enumeration. Here is the basic usage:
     331It is convenient to iterate over a \CFA enumeration.
     332Here is the basic usage:
    310333\begin{lstlisting}[label=lst:range_functions]
    311 for ( Alphabet ch; Alphabet; ) {
    312     printf( "%d ", ch );
     334for ( Alphabet ah; Alphabet; ) {
     335        printf( "%d ", ah );
    313336}
    314337>>> A B C (...omit the rest)
    315 
    316 \end{lstlisting}
    317 The for-loop uses the enumeration type @Alphabet@ as range. When that happens, \CFA iterates all enumerators in the order they defined in the enumeration. 'ch' is the iterating enumerator, and it returns the value of an Alphabet in this context according to the precedence rule.
     338\end{lstlisting}
     339The for-loop uses the enumeration type @Alphabet@ as range.
     340When that happens, \CFA iterates all enumerators in the order they defined in the enumeration.
     341@'ch'@ is the iterating enumerator, and it returns the value of an Alphabet in this context according to the precedence rule.
    318342
    319343\CFA offers a shorthand for iterating all enumeration constants:
    320344\begin{lstlisting}[label=lst:range_functions]
    321345for ( Alphabet ch ) {
    322     printf( "%d ", ch );
     346        printf( "%d ", ch );
    323347}
    324348>>> A B C (...omit the rest)
     
    331355for ( Alphabet ch; Alphabet.R ~ Alphabet.X ~ 2 )
    332356\end{lstlisting}
    333 
    334 Notably, the meaning of "step" of iteration has changed for enumeration. Consider the following example:
     357Notably, the meaning of "step" of iteration has changed for enumeration.
     358Consider the following example:
    335359\begin{lstlisting}[label=lst:range_functions]
    336360enum(int) Sequence {
    337     A = 10, B = 12, C = 14; 
     361        A = 10, B = 12, C = 14; 
    338362}
    339363for ( s; Sequence.A ~ Sequence.C ) {
    340     printf( "%d ", s );
     364        printf( "%d ", s );
    341365}
    342366
     
    344368
    345369for ( s; Sequence.A ~ Sequence.A ~ 2 ) {
    346     printf( "%d ", s );
     370        printf( "%d ", s );
    347371}
    348372>>> 10 14
    349373\end{lstlisting}
    350 The range iteration of enumeration does not return the $current\_value++$ until it reaches the upper bound. The semantics is to return the next enumeration constant. If a stepping is specified, 2 for example, it returns the 2 enumeration constant after the current one, rather than the $current+2$
     374The range iteration of enumeration does not return the @current_value++@ until it reaches the upper bound.
     375The semantics is to return the next enumeration constant.
     376If a stepping is specified, 2 for example, it returns the 2 enumeration constant after the current one, rather than the @current+2@.
    351377
    352378It is also possible to iterate over an enumeration's labels, implicitly or explicitly:
     
    354380for ( char * ch; Alphabet )
    355381\end{lstlisting}
    356 This for-loop implicitly iterates every label of the enumeration, because a label is the only valid resolution to the ch with type $char *$ in this case. If the value can also be resolved as the char *, you might iterate the labels explicitly with the array iteration.
     382This for-loop implicitly iterates every label of the enumeration, because a label is the only valid resolution to the ch with type @char *@ in this case.
     383If the value can also be resolved as the @char *@, you might iterate the labels explicitly with the array iteration.
    357384\begin{lstlisting}[label=lst:range_functions_label_implicit]
    358385for ( char * ch; labels( Alphabet ) )
     
    360387
    361388\section{Implementation}
     389
    362390\CFA places the definition of Companion structure and non-parameterized Companion functions in the prelude, visible globally.
    363391
    364 \subsection{declaration}
     392\subsection{Declaration}
     393
    365394The qualified enumeration syntax is dedicated to \CFA enumeration.
    366395\begin{lstlisting}[label=lst:range_functions]
    367396enum (type_declaration) name { enumerator = const_expr, enumerator = const_expr, ... }
    368397\end{lstlisting}
    369 A compiler stores the name, the underlying type, and all enumerators in an @enumeration table@. During the $Validation$ pass, the compiler links the type declaration to the type's definition. It ensures that the name of an enumerator is unique within the enumeration body, and checks if all values of the enumerator have the declaration type. If the declared type is not @Auto Initializable@, \CFA rejects the enumeration definition. Otherwise, it attempts to initialize enumerators with the enumeration initialization pattern. (a reference to a future initialization pattern section)
     398A compiler stores the name, the underlying type, and all enumerators in an @enumeration table@.
     399During the $Validation$ pass, the compiler links the type declaration to the type's definition.
     400It ensures that the name of an enumerator is unique within the enumeration body, and checks if all values of the enumerator have the declaration type.
     401If the declared type is not @Auto Initializable@, \CFA rejects the enumeration definition.
     402Otherwise, it attempts to initialize enumerators with the enumeration initialization pattern. (a reference to a future initialization pattern section)
    370403
    371404\begin{lstlisting}[label=lst:init]
     
    376409
    377410enum (T) Sample {
    378     Zero: 0 /* zero_t */,
    379     One: Zero + 1 /* ?+?( Zero, one_t ) */ , ...
    380 };
    381 \end{lstlisting}
    382 
    383 Challenge:
    384 The value of an enumerator, or the initializer, requires $const\_expr$. While previously getting around the issue by pushing it to the C compiler, it might not work anymore because of the user-defined types, user-defined $zero\_t$, $one\_t$, and addition operation. Might not be able to implement a *Correct* static check.
     411        Zero: 0 /* zero_t */,
     412        One: Zero + 1 /* ?+?( Zero, one_t ) */ , ...
     413};
     414\end{lstlisting}
     415Challenge: \\
     416The value of an enumerator, or the initializer, requires @const_expr@.
     417While previously getting around the issue by pushing it to the C compiler, it might not work anymore because of the user-defined types, user-defined @zero_t@, @one_t@, and addition operation.
     418Might not be able to implement a \emph{correct} static check.
    385419
    386420\CFA $autogens$ a Companion object for the declared enumeration.
    387421\begin{lstlisting}[label=lst:companion]
    388422Companion( T ) Sample {
    389     .values: { 0, 0+1, 0+1+1, 0+1+1+1, ... }, /* 0: zero_t, 1: one_t, +: ?+?{} */
    390     .labels: { "Zero", "One", "Two", "Three", ...},
    391     .length: /* number of enumerators */
    392 };
    393 \end{lstlisting}
    394 \CFA stores values as intermediate expressions because the result of the function call to the function $?+?{}(T\&, T\&)$ is statically unknown to \CFA. But the result will be computed in run time, and the compiler ensures the $values$ will not be changed.
     423        .values: { 0, 0+1, 0+1+1, 0+1+1+1, ... }, /* 0: zero_t, 1: one_t, +: ?+?{} */
     424        .labels: { "Zero", "One", "Two", "Three", ...},
     425        .length: /* number of enumerators */
     426};
     427\end{lstlisting}
     428\CFA stores values as intermediate expressions because the result of the function call to the function @?+?{}(T&, T&)@ is statically unknown to \CFA.
     429But the result is computed at run time, and the compiler ensures the @values@ are not changed.
    395430
    396431\subsection{qualified expression}
     432
    397433\CFA uses qualified expression to address the scoping of \CFA-enumeration.
    398434\begin{lstlisting}[label=lst:qualified_expression]
    399435aggregation_name.field;
    400436\end{lstlisting}
    401 The qualified expression is not dedicated to \CFA enumeration. It is a feature that is supported by other aggregation in \CFA as well, including a C enumeration. When C enumerations are unscoped, the qualified expression syntax still helps to disambiguate names in the context. \CFA recognizes if the expression references a \CFA aggregation by searching the presence of $aggregation\_name$ in the \CFA enumeration table. If the $aggregation\_name$ is identified as a \CFA enumeration, the compiler checks if $field$ presents in the declared \CFA enumeration.
    402 
    403 \subsection{with statement/statement}
    404 @Working in Progress@
    405 Instead of qualifying an enumeration expression every time, one can use the $with$ to expose enumerators to the current scope so that they are directly accessible.
    406 
    407 \subsection{instance declaration}
    408 @Working in Progress@
     437The qualified expression is not dedicated to \CFA enumeration.
     438It is a feature that is supported by other aggregation in \CFA as well, including a C enumeration.
     439When C enumerations are unscoped, the qualified expression syntax still helps to disambiguate names in the context.
     440\CFA recognizes if the expression references a \CFA aggregation by searching the presence of @aggregation_name@ in the \CFA enumeration table.
     441If the @aggregation_name@ is identified as a \CFA enumeration, the compiler checks if @field@ presents in the declared \CFA enumeration.
     442
     443\subsection{\lstinline{with} statement/statement}
     444
     445\emph{Work in Progress}
     446
     447Instead of qualifying an enumeration expression every time, one can use the @with@ to expose enumerators to the current scope so that they are directly accessible.
     448
     449\subsection{Instance Declaration}
     450
     451\emph{Work in Progress}
     452
    409453\begin{lstlisting}[label=lst:declaration]
    410454enum Sample s1;
    411455Sample s2;
    412456\end{lstlisting}
    413 A declaration of \CFA enumeration instance that has no difference than a C enumeration or other \CFA aggregation. The compiler recognizes the type of a variable declaration by searching the name in all possible types. The \textit{enum} keyword is not necessary but helps to disambiguate types (questionable). The generated code for a \CFA enumeration declaration is utterly an integer, which is meant to store the position.
     457A declaration of \CFA enumeration instance that has no difference than a C enumeration or other \CFA aggregation.
     458The compiler recognizes the type of a variable declaration by searching the name in all possible types.
     459The @enum@ keyword is not necessary but helps to disambiguate types (questionable).
     460The generated code for a \CFA enumeration declaration is utterly an integer, which is meant to store the position.
    414461\begin{lstlisting}[label=lst:declaration]
    415462int s1;
     
    418465
    419466\subsection{Compiler Representation}
    420 @Working in Progress@
    421 
    422 The internal representation of an enumeration constant is \textit{EnumInstType}. The minimum information an \textit{EnumInstType} stores is a reference to the \CFA-enumeration declaration and the position of the enumeration constant.
     467
     468\emph{Work in Progress}
     469
     470The internal representation of an enumeration constant is @EnumInstType@.
     471The minimum information an @EnumInstType@ stores is a reference to the \CFA-enumeration declaration and the position of the enumeration constant.
    423472\begin{lstlisting}[label=lst:EnumInstType]
    424473class EnumInstType {
    425     EnumDecl enumDecl;
    426     int position;
    427 };
    428 \end{lstlisting}
    429 
    430 
    431 \subsection{unification and resolution }
    432 @Working in Progress@
     474        EnumDecl enumDecl;
     475        int position;
     476};
     477\end{lstlisting}
     478
     479\subsection{Unification and Resolution }
     480
     481\emph{Work in Progress}
    433482
    434483\begin{lstlisting}
    435484enum Colour( char * ) { Red = "R", Green = "G", Blue = "B"  };
    436485\end{lstlisting}
    437 The EnumInstType is convertible to other types. A \CFA enumeration expression is implicitly "overloaded" with its three different attributes: value, position, and label. The \CFA compilers need to resolve an EnumInstType as one of its attributes based on the current context.
     486The @EnumInstType@ is convertible to other types.
     487A \CFA enumeration expression is implicitly \emph{overloaded} with its three different attributes: value, position, and label.
     488The \CFA compilers need to resolve an @EnumInstType@ as one of its attributes based on the current context.
    438489
    439490\begin{lstlisting}[caption={Null Context}, label=lst:null_context]
    440491{
    441     Colour.Green;
    442 }
    443 \end{lstlisting}
    444 In the example~\ref{lst:null_context}, the environment gives no information to help with the resolution of $Colour.Green$. In this case, any of the attributes is resolvable. According to the \textit{precedence rule}, the expression with EnumInstType will be resolved as $value( Colour.Green )$. The EnumInstType is converted to the type of the value, which is statically known to the compiler as char *. When the compilation reaches the code generation, the compiler outputs code for type char * with the value "G".
     492        Colour.Green;
     493}
     494\end{lstlisting}
     495In example~\ref{lst:null_context}, the environment gives no information to help with the resolution of @Colour.Green@.
     496In this case, any of the attributes is resolvable.
     497According to the \textit{precedence rule}, the expression with @EnumInstType@ resolves as @value( Colour.Green )@.
     498The @EnumInstType@ is converted to the type of the value, which is statically known to the compiler as @char *@.
     499When the compilation reaches the code generation, the compiler outputs code for type @char *@ with the value @"G"@.
    445500\begin{lstlisting}[caption={Null Context Generated Code}, label=lst:null_context]
    446501{
    447     "G";
    448 }
    449 \end{lstlisting}
    450 
    451  
     502        "G";
     503}
     504\end{lstlisting}
    452505\begin{lstlisting}[caption={int Context}, label=lst:int_context]
    453506{
    454     int g = Colour.Green;
    455 }
    456 \end{lstlisting}
    457 
    458 The assignment expression gives a context for the EnumInstType resolution. The EnumInstType is used as an int, and \CFA needs to determine which of the attributes can be resolved as an int type.
    459 The functions $Unify( T1, T2 ): bool$ take two types as parameters and determine if one type can be used as another. In the example\ref{lst:int_context} example, the compiler is trying to unify int and EnumInstType of Colour.
    460 $$Unification( int, EnumInstType<Colour> )$$
    461 which turns into three Unification call
     507        int g = Colour.Green;
     508}
     509\end{lstlisting}
     510The assignment expression gives a context for the EnumInstType resolution.
     511The EnumInstType is used as an @int@, and \CFA needs to determine which of the attributes can be resolved as an @int@ type.
     512The functions $Unify( T1, T2 ): bool$ take two types as parameters and determine if one type can be used as another.
     513In example~\ref{lst:int_context}, the compiler is trying to unify @int@ and @EnumInstType@ of @Colour@.
     514$$Unification( int, EnumInstType<Colour> )$$ which turns into three Unification call
    462515\begin{lstlisting}[label=lst:attr_resolution_1]
    463516{
    464     Unify( int, char * ); // unify with the type of value
    465     Unify( int, int ); // unify with the type of position
    466     Unify( int, char * ); // unify with the type of label
    467 }
    468 \end{lstlisting}
    469 
     517        Unify( int, char * ); // unify with the type of value
     518        Unify( int, int ); // unify with the type of position
     519        Unify( int, char * ); // unify with the type of label
     520}
     521\end{lstlisting}
    470522\begin{lstlisting}[label=lst:attr_resolution_precedence]
    471523{
    472     Unification( T1, EnumInstType<T2> ) {
    473         if ( Unify( T1, T2 ) ) return T2;
    474         if ( Unify( T1, int ) ) return int;
    475         if ( Unify( T1, char * ) ) return char *;
    476         Error: Cannot Unify T1 with EnumInstType<T2>;
    477     }
    478 }
    479 \end{lstlisting}
    480 After the unification, EnumInstType will be replaced by its attributes.
     524        Unification( T1, EnumInstType<T2> ) {
     525                if ( Unify( T1, T2 ) ) return T2;
     526                if ( Unify( T1, int ) ) return int;
     527                if ( Unify( T1, char * ) ) return char *;
     528                Error: Cannot Unify T1 with EnumInstType<T2>;
     529        }
     530}
     531\end{lstlisting}
     532After the unification, @EnumInstType@ is replaced by its attributes.
    481533
    482534\begin{lstlisting}[caption={Unification Functions}, label=lst:unification_func_call]
    483535{
    484     T2 foo ( T1 ); // function take variable with T1 as a parameter
    485     foo( EnumInstType<T3> ); // Call foo with a variable has type EnumInstType<T3>
    486     >>>> Unification( T1, EnumInstType<T3> )
    487 }
    488 \end{lstlisting}
    489 
     536        T2 foo ( T1 ); // function take variable with T1 as a parameter
     537        foo( EnumInstType<T3> ); // Call foo with a variable has type EnumInstType<T3>
     538        >>>> Unification( T1, EnumInstType<T3> )
     539}
     540\end{lstlisting}
    490541% The conversion can work backward: in restrictive cases, attributes of can be implicitly converted back to the EnumInstType.
    491542Backward conversion:
    492543\begin{lstlisting}[caption={Unification Functions}, label=lst:unification_func_call]
    493544{
    494     enum Colour colour = 1;
     545        enum Colour colour = 1;
    495546}
    496547\end{lstlisting}
     
    501552}
    502553\end{lstlisting}
    503 int can be unified with the label of Colour. "5" is a constant expression -> Compiler knows the value during the compilation -> turns it into
     554@int@ can be unified with the label of Colour.
     555@5@ is a constant expression $\Rightarrow$ Compiler knows the value during the compilation $\Rightarrow$ turns it into
    504556\begin{lstlisting}
    505557{
     
    508560\end{lstlisting}
    509561Steps:
    510 1: identify "1" as a constant expression with type int, and the value is statically known as 1
    511 2. unification( EnumInstType<Colour>, int ): position( EnumInstType< Colour > )
    512 3. return the enumeration constant at the position 1
    513 
     562\begin{enumerate}
     563\item
     564identify @1@ as a constant expression with type @int@, and the value is statically known as @1@
     565\item
     566@unification( EnumInstType<Colour>, int )@: @position( EnumInstType< Colour > )@
     567\item
     568return the enumeration constant at the position 1
     569\end{enumerate}
    514570\begin{lstlisting}
    515571{
    516     enum T (int) { ... } // Declaration
    517     enum T t = 1;
     572        enum T (int) { ... } // Declaration
     573        enum T t = 1;
    518574}
    519575\end{lstlisting}
    520576Steps:
    521 1: identify "1" as a constant expression with type int, and the value is statically known as 1
    522 2. unification( EnumInstType<Colour>, int ): value( EnumInstType< Colour > )
    523 3. return the FIRST enumeration constant that has the value 1, by searching through the values array
    524 
    525 The downside of the precedence rule: EnumInstType -> int ( value ) -> EnumInstType may return a different EnumInstType because the value can be repeated and there is no way to know which one is expected -> want uniqueness
     577\begin{enumerate}
     578\item
     579identify @1@ as a constant expression with type @int@, and the value is statically known as @1@
     580\item
     581@unification( EnumInstType<Colour>, int )@: @value( EnumInstType< Colour > )@
     582\item
     583return the FIRST enumeration constant that has the value 1, by searching through the values array
     584\end{enumerate}
     585The downside of the precedence rule: @EnumInstType@ $\Rightarrow$ @int ( value )@ $\Rightarrow$ @EnumInstType@ may return a different @EnumInstType@ because the value can be repeated and there is no way to know which one is expected $\Rightarrow$ want uniqueness
    526586
    527587\end{document}
Note: See TracChangeset for help on using the changeset viewer.