Index: doc/theses/jiada_liang_MMath/CFAenum.tex =================================================================== --- doc/theses/jiada_liang_MMath/CFAenum.tex (revision 9464369822b752daa3680a739289ebb9f7b7665a) +++ doc/theses/jiada_liang_MMath/CFAenum.tex (revision c588acbb75d8c5916e6a5ee323923484f09ba429) @@ -1,12 +1,13 @@ \chapter{\CFA Enumeration} -% \CFA supports C enumeration using the same syntax and semantics for backwards compatibility. -% \CFA also extends C-Style enumeration by adding a number of new features that bring enumerations inline with other modern programming languages. -% Any enumeration extensions must be intuitive to C programmers both in syntax and semantics. -% The following sections detail all of my new contributions to enumerations in \CFA. -\CFA extends the enumeration declaration by parameterizing with a type (like a generic type). - - -\begin{cfa}[caption={CFA Enum},captionpos=b,label={l:CFAEnum}] +\CFA extends C-Style enumeration by adding a number of new features that bring enumerations inline with other modern programming languages. +Any enumeration extensions must be intuitive to C programmers both in syntax and semantics. +The following sections detail all of my new contributions to enumerations in \CFA. + + +\section{Enumeration Syntax} + +\CFA extends the C enumeration declaration \see{\VRef{s:CEnumeration}} by parameterizing with a type (like a generic type), and adding Plan-9 inheritance \see{\VRef{s:EnumerationInheritance}} using an @inline@ to another enumeration type. +\begin{cfa}[identifierstyle=\linespread{0.9}\it] $\it enum$-specifier: enum @(type-specifier$\(_{opt}\)$)@ identifier$\(_{opt}\)$ { cfa-enumerator-list } @@ -15,52 +16,78 @@ cfa-enumerator-list: cfa-enumerator - cfa-enumerator, cfa-enumerator-list + cfa-enumerator-list, cfa-enumerator cfa-enumerator: enumeration-constant - $\it inline$ identifier - enumeration-constant = expression -\end{cfa} - -A \newterm{\CFA enumeration}, or \newterm{\CFA enum}, has an optional type declaration in the bracket next to the @enum@ keyword. -Without optional type declarations, the syntax defines \newterm{opaque enums}. -Otherwise, \CFA enum with type declaration are \newterm{typed enums}. - -\section{Opaque Enum} + @inline $\color{red}enum$-type-name@ + enumeration-constant = constant-expression +\end{cfa} + + +\section{Enumeration Operations} + +\CFA enumerations have access to the three enumerations properties \see{\VRef{s:Terminology}}: label, order (position), and value via three overloaded functions @label@, @posn@, and @value@ \see{\VRef{c:trait} for details}. +\CFA auto-generates these functions for every \CFA enumeration. +\begin{cfa} +enum(int) E { A = 3 } e = A; +sout | A | @label@( A ) | @posn@( A ) | @value@( A ); +sout | e | @label@( e ) | @posn@( e ) | @value@( e ); +A A 0 3 +A A 0 3 +\end{cfa} +For output, the default is to print the label. +An alternate way to get an enumerator's position is to cast it to @int@. +\begin{cfa} +sout | A | label( A ) | @(int)A@ | value( A ); +sout | A | label( A ) | @(int)A@ | value( A ); +A A @0@ 3 +A A @0@ 3 +\end{cfa} +Finally, there is an additional enumeration routine @countof@ (like @sizeof@, @typeof@) that returns the number of enumerators in an enumeration. +\begin{cfa} +enum(int) E { A, B, C, D }; +countof( E ); // 4 +\end{cfa} +This auto-generated function replaces the C idiom for automatically computing the number of enumerators \see{\VRef{s:Usage}}. +\begin{cfa} +enum E { A, B, C, D, @N@ }; // N == 4 +\end{cfa} + +The underlying representation of \CFA enumeration object is its position, saved as an integral type. +Therefore, the size of a \CFA enumeration is consistent with a C enumeration. +Attribute function @posn@ performs type substitution on an expression from \CFA type to integral type. +The label and value of an enumerator is stored in a global data structure for each enumeration, where attribute functions @label@/@value@ map an \CFA enumeration object to the corresponding data. +These operations do not apply to C Enums because backwards compatibility means the necessary backing data structures cannot be supplied. + +\section{Opaque Enumeration} \label{s:OpaqueEnum} -Opaque enum is a special CFA enumeration type, where the internal representation is chosen by the compiler and hidden from users. -Compared C enum, opaque enums are more restrictive in terms of typing, and cannot be implicitly converted to integers. -Enumerators of opaque enum cannot have initializer. Declaring initializer in the body of opaque enum results in a compile time error. -\begin{cfa} -enum@()@ Planets { MERCURY, VENUS, EARTH, MARS, JUPITER, SATURN, URANUS, NEPTUNE }; - -Planet p = URANUS; -int i = VENUS; @// Error, VENUS cannot be converted into an integral type -\end{cfa} -% Each opaque enum has two @attributes@: @position@ and @label@. \CFA auto-generates @attribute functions@ @posn()@ and @label()@ for every \CFA enum to returns the respective attributes. -Opaque enumerations have two defining properties: @label@ (name) and @order@ (position), exposed to users by predefined @attribute functions@ , with the following signatures: -\begin{cfa} -forall( E ) { - unsigned posn(E e); - const char * s label(E e); -}; -\end{cfa} -With polymorphic type parameter E being substituted by enumeration types such as @Planet@. - -\begin{cfa} -unsigned i = posn(VENUS); // 1 -char * s = label(MARS); // "MARS" -\end{cfa} - -\subsection{Representation} -The underlying representation of \CFA enumeration object is its order, saved as an integral type. Therefore, the size of a \CFA enumeration is consistent with C enumeration. -Attribute function @posn@ performs type substitution on an expression from \CFA type to integral type. -Names of enumerators are stored in a global data structure, with @label@ maps \CFA enumeration object to corresponding data. - -\section{Typed Enum} + +When an enumeration type is empty is it an \newterm{opaque} enumeration. +\begin{cfa} +enum@()@ Mode { O_RDONLY, O_WRONLY, O_CREAT, O_TRUNC, O_APPEND }; +\end{cfa} +Here, the internal representation is chosen by the compiler and hidden, so the enumerators cannot be initialized. +Compared to the C enum, opaque enums are more restrictive in terms of typing and cannot be implicitly converted to integers. +\begin{cfa} +Mode mode = O_RDONLY; +int www @=@ mode; $\C{// disallowed}$ +\end{cfa} +Opaque enumerations have only two attribute properties @label@ and @posn@. +\begin{cfa} +char * s = label( O_TRUNC ); $\C{// "O\_TRUNC"}$ +int open = posn( O_WRONLY ); $\C{// 1}$ +\end{cfa} +The equality and relational operations are available. +\begin{cfa} +if ( mode @==@ O_CREAT ) ... +bool b = mode @<@ O_APPEND; +\end{cfa} + + +\section{Typed Enumeration} \label{s:EnumeratorTyping} -\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. +When an enumeration type is specified, all enumerators have that type and can be initialized with constants of that type or compile-time convertable to that 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 values used to set the enumerator constants. -Note, the synonyms @Liz@ and @Beth@ in the last declaration. +Note, the use of the synonyms @Liz@ and @Beth@ in the last declaration. Because enumerators are constants, the enumeration type is implicitly @const@, so all the enumerator types in Figure~\ref{f:EumeratorTyping} are logically rewritten with @const@. @@ -86,7 +113,8 @@ // aggregate struct Person { char * name; int age, height; }; -@***@enum( @Person@ ) friends { @Liz@ = { "ELIZABETH", 22, 170 }, @Beth@ = Liz, + enum( @Person@ ) friends { @Liz@ = { "ELIZABETH", 22, 170 }, @Beth@ = Liz, Jon = { "JONATHAN", 35, 190 } }; \end{cfa} +% synonym feature unimplemented \caption{Enumerator Typing} \label{f:EumeratorTyping} @@ -104,112 +132,83 @@ Note, the enumeration type can be a structure (see @Person@ in Figure~\ref{f:EumeratorTyping}), so it is possible to have the equivalent of multiple arrays of companion data using an array of structures. -While the enumeration type can be any C aggregate, the aggregate's \CFA constructors are not used to evaluate an enumerator's value. +While the enumeration type can be any C aggregate, the aggregate's \CFA constructors are \emph{not} used to evaluate an enumerator's value. \CFA enumeration constants are compile-time values (static); calling constructors happens at runtime (dynamic). -@value@ is an @attribute@ that defined for typed enum along with position and label. @values@ of a typed enum are stored in a global array of declared typed, initialized with -value of enumerator initializers. @value()@ functions maps an enum to an elements of the array. - - -\subsection{Value Conversion} + +\section{Value Conversion} + C has an implicit type conversion from an enumerator to its base type @int@. -Correspondingly, \CFA has an implicit conversion from a typed enumerator to its base type, allowing typed enumeration to be seemlyless used as -a value of its base type. -\begin{cfa} -char currency = Dollar; -void foo( char * ); -foo( Fred ); -\end{cfa} - -% During the resolution of expression e with \CFA enumeration type, \CFA adds @value(e)@ as an additional candidate with an extra \newterm{value} cost. -% For expression @char currency = Dollar@, the is no defined conversion from Dollar (\CFA enumeration) type to basic type and the conversion cost is @infinite@, -% thus the only valid candidate is @value(Dollar)@. -The implicit conversion induces a \newterm{value cost}, which is a new category in \CFA's conversion cost model to disambiguate function overloading over for both \CFA enumeration and its base type. +Correspondingly, \CFA has an implicit conversion from a typed enumerator to its base type, allowing typed enumeration to be seamlessly used as the value of its base type +For example, using type @Currency@ in \VRef[Figure]{f:EumeratorTyping}: +\begin{cfa} +char currency = Dollar; $\C{// implicit conversion to base type}$ +void foo( char ); +foo( Dollar ); $\C{// implicit conversion to base type}$ +\end{cfa} +The implicit conversion induces a \newterm{value cost}, which is a new category (8 tuple) in \CFA's conversion cost model \see{\VRef{s:ConversionCost}} to disambiguate function overloading over a \CFA enumeration and its base type. \begin{cfa} void baz( char ch ); $\C{// (1)}$ void baz( Currency cu ); $\C{// (2)}$ - -baz( Cent ); -\end{cfa} -While both baz are applicable to \CFA enumeration, using Cent as a char in @candiate (1)@ comes with a @value@ cost, -while @candidate (2)@ has @zero@ cost. \CFA always choose a overloaded candidate implemented for a \CFA enumeration itself over a candidate applies on a base type. - -Value cost is defined to be a more significant factor than an @unsafe@ but weight less than @poly@. -With @value@ being an additional category, the current \CFA conversion cost is a 8-tuple: -@@(unsafe, value, poly, safe, sign, vars, specialization, reference)@@. - -\begin{cfa} -void bar(int); -enum(int) Month !{ - January=31, February=29, March=31, April=30, May=31, June-30, - July=31, August=31, September=30, October=31, November=30, December=31 -}; - -Month a = Februrary; $\C{// (1), with cost (0, 1, 0, 0, 0, 0, 0, 0)}$ -double a = 5.5; $\C{// (2), with cost (1, 0, 0, 0, 0, 0, 0, 0)}$ - -bar(a); -\end{cfa} -In the previous example, candidate (1) has an value cost to parameter type int, with is lower than (2) as an unsafe conversion from double to int. -\CFA chooses value cost over unsafe cost and therefore @a@ of @bar(a)@ is resolved as an @Month@. - -\begin{cfa} -forall(T | @CfaEnum(T)@) void bar(T); - -bar(a); $\C{// (3), with cost (0, 0, 1, 0, 0, 0, 0, 0)}$ -\end{cfa} -% @Value@ is designed to be less significant than @poly@ to allow function being generic over \CFA enumeration (see ~\ref{c:trait}). -Being generic over @CfaEnum@ traits (a pre-defined interface for \CFA enums) is a practice in \CFA to implement functions over \CFA enumerations, as will see in chapter~\ref{c:trait}. -@Value@ is a being a more significant cost than @poly@ implies if a overloaeded function defined for @CfaEnum@ (and other generic type), \CFA always -try to resolve it as a @CfaEnum@, rather to insert a @value@ conversion. - -\subsection{Explicit Conversion} -Explicit conversion is allowed on \CFA enumeration to an integral type, in which case \CFA converts \CFA enumeration into its underlying representation, -which is its @position@. - -\section{Auto Initialization} - -C auto-initialization works for the integral type @int@ with constant expressions. -\begin{cfa} -enum Alphabet ! { - A = 'A', B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, - a = 'a', b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z -}; -\end{cfa} -The complexity of the constant expression depends on the level of runtime computation the compiler implements, \eg \CC \lstinline[language={[GNU]C++}]{constexpr} provides complex compile-time computation across multiple types, which blurs the compilation/runtime boundary. - -% The notion of auto-initialization is generalized in \CFA enumertation E with base type T in the following way: -When an enumerator @e@ does not have a initializer, if @e@ has enumeration type @E@ with base type @T@, \CFA auto-initialize @e@ with the following scheme: +baz( Dollar ); +\end{cfa} +While both @baz@ functions are applicable to the enumerator @Dollar@, @candidate (1)@ comes with a @value@ cost for the conversion to the enumeration's base type, while @candidate (2)@ has @zero@ cost. +Hence, \CFA chooses the exact match. +Value cost is defined to be a more significant factor than an @unsafe@ but less than the other conversion costs: @(unsafe,@ {\color{red}@value@}@, poly, safe, sign, vars, specialization,@ @reference)@. +\begin{cfa} +void bar( @int@ ); +Math x = PI; $\C{// (1)}$ +double x = 5.5; $\C{// (2)}$ +bar( x ); $\C{// costs (1, 0, 0, 0, 0, 0, 0, 0) or (0, 1, 0, 0, 0, 0, 0, 0)}$ +\end{cfa} +Here, candidate (1) has a value conversion cost to convert to the base type, while candidate (2) has an unsafe conversion from @double@ to @int@. +Hence, @bar( x )@ resolves @x@ as type @Math@. + +% \begin{cfa} +% forall(T | @CfaEnum(T)@) void bar(T); +% +% bar(a); $\C{// (3), with cost (0, 0, 1, 0, 0, 0, 0, 0)}$ +% \end{cfa} +% % @Value@ is designed to be less significant than @poly@ to allow function being generic over \CFA enumeration (see ~\ref{c:trait}). +% Being generic over @CfaEnum@ traits (a pre-defined interface for \CFA enums) is a practice in \CFA to implement functions over \CFA enumerations, as will see in chapter~\ref{c:trait}. +% @Value@ is a being a more significant cost than @poly@ implies if a overloaeded function defined for @CfaEnum@ (and other generic type), \CFA always try to resolve it as a @CfaEnum@, rather to insert a @value@ conversion. + + +\section{Auto Initialization} + +A partially implemented feature is auto-initialization, which works for the C integral type with constant expressions. +\begin{cfa} +enum Week { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun }; // 0-2, 10-13 +\end{cfa} +The complexity of the constant expression depends on the level of computation the compiler implements, \eg \CC \lstinline[language={[GNU]C++}]{constexpr} provides complex compile-time computation across multiple types, which blurs the compilation/runtime boundary. + +If \CFA had powerful compilation expression evaluation, auto initialization would be implemented as follows. +\begin{cfa} +enum E(T) { A, B, C }; +\end{cfa} \begin{enumerate} -% \item Enumerator e is the first enumerator of \CFA enumeration E with base type T. If e declares no no initializer, e is auto-initialized by the $zero\_t$ constructor of T. -\item if e is first enumerator, e is initialized with T's @zero_t@. -\item otherwise, if d is the enumerator defined just before e, with d has has been initialized with expression @l@ (@l@ can also be an auto-generated), e is initialized with @l++@. -% \CFA reports a compile time error if T has no $zero\_t$ constructor. -% Enumerator e is an enumerator of base-type T enumeration E that position i, where $i \neq 0$. And d is the enumerator with position @i-1@, e is auto-initialized with -% the result of @value(d)++@. If operator @?++@ is not defined for type T, \CFA reports a compile time error. - -% Unfortunately, auto-initialization is not implemented because \CFA is only a transpiler, relying on generated C code to perform the detail work. -% C does not have the equivalent of \CC \lstinline[language={[GNU]C++}]{constexpr}, and it is currently beyond the scope of the \CFA project to implement a complex runtime interpreter in the transpiler. -% Nevertheless, the necessary language concepts exist to support this feature. +\item the first enumerator, @A@, is initialized with @T@'s @zero_t@. +\item otherwise, the next enumerator is initialized with the previous enumerator's value using operator @?++@, where @?++( T )@ can be overloaded for any type @T@. \end{enumerate} -while @?++( T )@ can be explicitly overloaded or implicitly overloaded with properly defined @one_t@ and @?+?(T, T)@. - -Unfortunately, auto-initialization with only constant expression is not enforced because \CFA is only a transpiler, relying on generated C code to perform the detail work. -C does not have the equivalent of \CC \lstinline[language={[GNU]C++}]{constexpr}, and it is currently beyond the scope of the \CFA project to implement a complex runtime interpreter in the transpiler. + +Unfortunately, constant expressions in C are not powerful and \CFA is only a transpiler, relying on generated C code to perform the detail work. +It is currently beyond the scope of the \CFA project to implement a complex runtime interpreter in the transpiler to evaluate complex expressions across multiple builtin and user-defined type. Nevertheless, the necessary language concepts exist to support this feature. + \section{Enumeration Inheritance} +\label{s:EnumerationInheritance} \CFA Plan-9 inheritance may be used with \CFA enumerations, where Plan-9 inheritance is containment inheritance with implicit unscoping (like a nested unnamed @struct@/@union@ in C). -Containment is norminative: an enumeration inherits all enumerators from another enumeration by declaring an @inline statement@ in its enumerator lists. -\begin{cfa} -enum( char * ) Names { /* as above */ }; +Containment is nominative: an enumeration inherits all enumerators from another enumeration by declaring an @inline statement@ in its enumerator lists. +\begin{cfa} +enum( char * ) Names { /* $\see{\VRef[Figure]{s:EnumerationInheritance}}$ */ }; enum( char * ) Names2 { @inline Names@, Jack = "JACK", Jill = "JILL" }; enum( char * ) Names3 { @inline Names2@, Sue = "SUE", Tom = "TOM" }; \end{cfa} In the preceding example, @Names2@ is defined with five enumerators, three of which are from @Name@ through containment, and two are self-declared. -@Names3@ inherits all five members from @Names2@ and declare two additional enumerators. - -Enumeration inheritance forms a subset relationship. Specifically, the inheritance relationship for the example above is: +@Names3@ inherits all five members from @Names2@ and declares two additional enumerators. +Hence, enumeration inheritance forms a subset relationship. +Specifically, the inheritance relationship for the example above is: \begin{cfa} Names $\(\subset\)$ Names2 $\(\subset\)$ Names3 $\C{// enum type of Names}$ @@ -217,60 +216,44 @@ Inheritance can be nested, and a \CFA enumeration can inline enumerators from more than one \CFA enumeration, forming a tree-like hierarchy. -However, the uniqueness of enumeration name applies to enumerators, including those from supertypes, meaning an enumeration cannot name enumerator with the same label as its subtype's members, or inherits -from multiple enumeration that has overlapping enumerator label. As a consequence, a new type cannot inherits from both an enumeration and its supertype, or two enumerations with a -common supertype (the diamond problem), since such would unavoidably introduce duplicate enumerator labels. - - -% 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, that 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. - - -% The enumeration base for the subtype must be the same as the super type. +However, the uniqueness of enumeration name applies to enumerators, including those from supertypes, meaning an enumeration cannot name enumerator with the same label as its subtype's members, or inherits +from multiple enumeration that has overlapping enumerator label. As a consequence, a new type cannot inherits from both an enumeration and its supertype, or two enumerations with a +common supertype (the diamond problem), since such would unavoidably introduce duplicate enumerator labels. + The base type must be consistent between subtype and supertype. -When an enumeration inherits enumerators from another enumeration, it copies the enumerators' @value@ and @label@, even if the @value@ was auto initialized. However, the @position@ as the underlying -representation will be the order of the enumerator in new enumeration. -% new enumeration @N@ copies all enumerators from @O@, including those @O@ obtains through inheritance. Enumerators inherited from @O@ -% keeps same @label@ and @value@, but @position@ may shift to the right if other enumerators or inline enumeration declared in prior of @inline A@. -% 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. - -\begin{cfa} -enum() Phynchocephalia { Tuatara }; -enum() Squamata { Snake, Lizard }; -enum() Lepidosauromorpha { inline Phynchocephalia, inline Squamata, Kuehneosauridae }; -\end{cfa} -Snake, for example, has the position 0 in Squamata, but 1 in Lepidosauromorpha as Tuatara inherited from Phynchocephalia is position 0 in Lepidosauromorpha. +When an enumeration inherits enumerators from another enumeration, it copies the enumerators' @value@ and @label@, even if the @value@ is auto initialized. +However, the position of the underlying representation is the order of the enumerator in the new enumeration. +\begin{cfa} +enum() E1 { A }; +enum() E2 { B, C }; +enum() E3 { inline E1, inline E2, D }; +\end{cfa} +Here, @A@ has position 0 in @E1@ and @E3@. +@B@ has position 0 in @E2@ and 1 in @E3@. +@C@ has position 1 in @E2@ and position 2 in @E3@. +@D@ has position 3 in @E3@. A subtype enumeration can be casted, or implicitly converted into its supertype, with a @safe@ cost. \begin{cfa} -enum Squamata squamata_lizard = Lizard; -posn(quamata_lizard); // 1 -enum Lepidosauromorpha lepidosauromorpha_lizard = squamata_lizard; -posn(lepidosauromorpha_lizard); // 2 -void foo( Lepidosauromorpha l ); -foo( squamata_lizard ); -posn( (Lepidosauromorpha) squamata_lizard ); // 2 - -Lepidosauromorpha s = Snake; -\end{cfa} -The last expression in the preceding example is unambiguous. While both @Squamata.Snake@ and @Lepidosauromorpha.Snake@ are valid candidate, @Squamata.Snake@ has -an associated safe cost and \CFA select the zero cost candidate @Lepidosauromorpha.Snake@. - -As discussed in \VRef{s:OpaqueEnum}, \CFA chooses position as a representation of \CFA enum. Conversion involves both change of typing -and possibly @position@. - -When converting a subtype to a supertype, the position can only be a larger value. The difference between the position in subtype and in supertype is an "offset". -\CFA runs a the following algorithm to determine the offset for an enumerator to a super type. -% In a summary, \CFA loops over members (include enumerators and inline enums) of the supertype. -% If the member is the matching enumerator, the algorithm returns its position. -% If the member is a inline enumeration, the algorithm trys to find the enumerator in the inline enumeration. If success, it returns the position of enumerator in the inline enumeration, plus -% the position in the current enumeration. Otherwises, it increase the offset by the size of inline enumeration. - +enum E2 e2 = C; +posn( e2 ); $\C[1.75in]{// 1}$ +enum E3 e3 = e2; +posn( e2 ); $\C{// 2}$ +void foo( E3 e ); +foo( e2 ); +posn( (E3)e2 ); $\C{// 2}$ +E3 e31 = B; +posn( e31 ); $\C{// 1}\CRT$ +\end{cfa} +The last expression is unambiguous. +While both @E2.B@ and @E3.B@ are valid candidate, @E2.B@ has an associated safe cost and \CFA selects the zero cost candidate @E3.B@. +Hence, as discussed in \VRef{s:OpaqueEnum}, \CFA chooses position as a representation of the \CFA enum. +Therefore, conversion involves both a change of type and possibly position. + +When converting a subtype to a supertype, its position can only be a larger value. +The difference between the position in the subtype and in the supertype is its \newterm{offset}. +\VRef[Figure]{s:OffsetSubtypeSuperType} show the algorithm to determine the offset for an subtype enumerator to its super type. +\PAB{You need to explain the algorithm.} + +\begin{figure} \begin{cfa} struct Enumerator; @@ -280,5 +263,5 @@ pair calculateEnumOffset( CFAEnum dst, Enumerator e ) { int offset = 0; - for( auto v: dst.members ) { + for ( auto v: dst.members ) { if ( v.holds_alternative() ) { auto m = v.get(); @@ -294,10 +277,8 @@ } \end{cfa} - -% \begin{cfa} -% Names fred = Name.Fred; -% (Names2) fred; (Names3) fred; (Name3) Names.Jack; $\C{// cast to super type}$ -% Names2 fred2 = fred; Names3 fred3 = fred2; $\C{// assign to super type}$ -% \end{cfa} +\caption{Compute Offset from Subtype Enumerator to Super Type} +\label{s:OffsetSubtypeSuperType} +\end{figure} + For the given function prototypes, the following calls are valid. \begin{cquote} @@ -319,4 +300,5 @@ \end{cquote} 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. + \section{Enumerator Control Structures} @@ -379,5 +361,5 @@ \begin{cfa} for ( cx; @Count@ ) { sout | cx | nonl; } sout | nl; -for ( cx; +~= Count ) { sout | cx | nonl; } sout | nl; +for ( cx; ~= Count ) { sout | cx | nonl; } sout | nl; for ( cx; -~= Count ) { sout | cx | nonl; } sout | nl; First Second Third Fourth @@ -390,6 +372,6 @@ C has an idiom for @if@ and loop predicates of comparing the predicate result ``not equal to 0''. \begin{cfa} -if ( x + y /* != 0 */ ) ... -while ( p /* != 0 */ ) ... +if ( x + y /* != 0 */ ) ... +while ( p /* != 0 */ ) ... \end{cfa} This idiom extends to enumerations because there is a boolean conversion in terms of the enumeration value, if and only if such a conversion is available. @@ -412,5 +394,5 @@ \section{Enumeration Dimension} -\VRef{s:EnumeratorTyping} introduced the harmonizing problem between an enumeration and secondary information. +\VRef{s:EnumeratorTyping} introduces the harmonizing problem between an enumeration and secondary information. When possible, using a typed enumeration for the secondary information is the best approach. However, there are times when combining these two types is not possible. @@ -422,17 +404,19 @@ enum E1 { A, B, C, N }; // possibly predefined enum(int) E2 { A, B, C }; -float H1[N] = { [A] :$\footnote{Note, C uses the symbol, @'='@ for designator initialization, but \CFA had to change to @':'@ because of problems with tuple syntax.}$ 3.4, [B] : 7.1, [C] : 0.01 }; // C +float H1[N] = { [A] :$\footnotemark$ 3.4, [B] : 7.1, [C] : 0.01 }; // C float H2[@E2@] = { [A] : 3.4, [B] : 7.1, [C] : 0.01 }; // CFA \end{cfa} +\footnotetext{C uses symbol \lstinline{'='} for designator initialization, but \CFA changes it to \lstinline{':'} because of problems with tuple syntax.} This approach is also necessary for a predefined typed enumeration (unchangeable), when additional secondary-information need to be added. -The array subscript operator, namely ?[?], has been overloaded so that when a CFA enumerator is used as an array index, it implicitly converts -to its position over value to sustain data hormonization. User can revert the behaviour by: -\begin{cfa} -float ?[?](float * arr, E2 index) { return arr[value(index)]; } -\end{cfa} -When an enumeration type is being used as an array dimension, \CFA add the enumeration type to initializer's context. As a result, -@H2@'s array destinators @A@, @B@ and @C@ are resolved unambiguously to type E2. (H1's destinators are also resolved unambiguously to -E1 because E2 has a @value@ cost to @int@). +The array subscript operator, namely @?[?]@, is overloaded so that when a \CFA enumerator is used as an array index, it implicitly converts to its position over value to sustain data harmonization. +This behaviour can be reverted by explicit overloading: +\begin{cfa} +float ?[?]( float * arr, E2 index ) { return arr[ value( index ) ]; } +\end{cfa} +When an enumeration type is being used as an array dimension, \CFA adds the enumeration type to the initializer's context. +As a result, @H2@'s array destinators @A@, @B@ and @C@ are resolved unambiguously to type @E2@. +(@H1@'s destinators are also resolved unambiguously to @E1@ because @E2@ has a @value@ cost.) + \section{Enumeration I/O} @@ -443,5 +427,5 @@ \VRef[Figure]{f:EnumerationI/O} show \CFA enumeration input based on the enumerator labels. When the enumerator labels are packed together in the input stream, the input algorithm scans for the longest matching string. -For basic types in \CFA, the constants use to initialize a variable in a program are available to initialize a variable using input, where strings constants can be quoted or unquoted. +For basic types in \CFA, the rule is that the same constants used to initialize a variable in a program are available to initialize a variable using input, where strings constants can be quoted or unquoted. \begin{figure} @@ -509,5 +493,5 @@ \small \begin{cfa} -struct MR { double mass, radius; }; $\C{// planet definition}$ +struct MR { double mass, radius; }; $\C[3.5in]{// planet definition}$ enum( @MR@ ) Planet { $\C{// typed enumeration}$ // mass (kg) radius (km) @@ -543,5 +527,5 @@ sout | rp | "is not a planet"; } - for ( @p; Planet@ ) { $\C{// enumerate}$ + for ( @p; Planet@ ) { $\C{// enumerate}\CRT$ sout | "Your weight on" | ( @p == MOON@ ? "the" : " " ) | p | "is" | wd( 1,1, surfaceWeight( p, earthMass ) ) | "kg";