Index: doc/theses/jiada_liang_MMath/CFAenum.tex =================================================================== --- doc/theses/jiada_liang_MMath/CFAenum.tex (revision 11cced628083f8f93238942878f2ae83b1267af1) +++ doc/theses/jiada_liang_MMath/CFAenum.tex (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) @@ -177,24 +177,24 @@ -\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 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} - -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{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 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} +% +% 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. @@ -263,13 +263,14 @@ posn( e2 ); $\C[1.75in]{// 0}$ enum E3 e3 = e2; $\C{// Assignment with enumeration conversion E2 to E3}$ -posn( e2 ); $\C{// 1 }$ +posn( e2 ); $\C{// 1 cost}$ void foo( E3 e ); foo( e2 ); $\C{// Type compatible with enumeration conversion E2 to E3}$ posn( (E3)e2 ); $\C{// Explicit cast with enumeration conversion E2 to E3}$ E3 e31 = B; $\C{// No conversion: E3.B}$ -posn( e31 ); $\C{// 0 }\CRT$ +posn( e31 ); $\C{// 0 cost}\CRT$ \end{cfa} The last expression is unambiguous. -While both @E2.B@ and @E3.B@ are valid candidates, @E2.B@ has an associated safe cost and @E3.B@ need not a conversion (@zero@ cost). \CFA selects the lowest cost candidate @E3.B@. +While both @E2.B@ and @E3.B@ are valid candidates, @E2.B@ has an associated safe cost and @E3.B@ needs no conversion (@zero@ cost). +\CFA selects the lowest cost candidate @E3.B@. For the given function prototypes, the following calls are valid. @@ -449,5 +450,4 @@ \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 @?[?]@, 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: @@ -455,10 +455,11 @@ float ?[?]( float * arr, E2 index ) { return arr[ value( index ) ]; } \end{cfa} -While enumerator labels @A@, @B@ and @C@ are being defined twice in different enumerations, they are -unambiguous within the context. Designators in H1 are unambiguous becasue @E2@ has a @value@ cost to @int@, which -is more expensive than @safe@ cost from C-Enum @E1@ to @int@. On the hand, designators in @H2@ are resolved as @E2@ because -when a \CFA enumeration type is being used as an array dimension, \CFA adds the enumeration type to the initializer's resolution context. +While enumerator labels @A@, @B@ and @C@ are being defined twice in different enumerations, they are unambiguous within the context. +Designators in @H1@ are unambiguous becasue @E2@ has a @value@ cost to @int@, which is more expensive than @safe@ cost from C-Enum @E1@ to @int@. +Designators in @H2@ are resolved as @E2@ because when a \CFA enumeration type is being used as an array dimension, \CFA adds the enumeration type to the initializer's resolution context. + \section{I/O} + As seen in multiple examples, \CFA enumerations can be printed and the default property printed is the enumerator's label, which is similar in other programming languages. However, very few programming languages provide a mechanism to read in enumerator values. Index: doc/theses/jiada_liang_MMath/Cenum.tex =================================================================== --- doc/theses/jiada_liang_MMath/Cenum.tex (revision 11cced628083f8f93238942878f2ae83b1267af1) +++ doc/theses/jiada_liang_MMath/Cenum.tex (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) @@ -15,9 +15,9 @@ enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$ \end{cfa} -There is no mechanism in C to resolve these naming conflicts other than renaming one of the duplicates, which may be impossible if the conflict comes from system-include files. +There is no mechanism in C to resolve these naming conflicts other than renaming one of the duplicates, which may be impossible if the conflict comes from system include-files. The \CFA type-system allows extensive overloading, including enumerators. Hence, most ambiguities among C enumerators are implicitly resolved by the \CFA type system, possibly without any programmer knowledge of the conflict. -In addition, C Enum qualification is added, exactly like aggregate field qualification, to disambiguate. +In addition, C Enum qualification is added, exactly like aggregate field-qualification, to disambiguate. \VRef[Figure]{f:EnumeratorVisibility} shows how resolution, qualification, and casting are used to disambiguate situations for enumerations @E1@ and @E2@. @@ -68,4 +68,5 @@ \section{Type Safety} +\label{s:TypeSafety} As in Section~\ref{s:Usage}, C's implicit bidirectional conversion between enumeration and integral type raises a safety concern. @@ -101,21 +102,2 @@ \item[How widely used:] Common. \end{description} - -\begin{comment} -\begin{description}[parsep=0pt] -\item[Change:] In \CC, the type of an enumerator is its enumeration. -In C, the type of an enumerator is @int@. -Example: -\begin{cfa} -enum e { A }; -sizeof(A) == sizeof(int) $\C{// in C}$ -sizeof(A) == sizeof(e) $\C{// in \CC}$ -/* and sizeof(int) is not necessary equal to sizeof(e) */ -\end{cfa} -\item[Rationale:] In \CC, an enumeration is a distinct type. -\item[Effect on original feature:] Change to semantics of well-defined feature. -\item[Difficulty of converting:] Semantic transformation. -\item[How widely used:] Seldom. The only time this affects existing C code is when the size of an enumerator is -taken. Taking the size of an enumerator is not a common C coding practice. -\end{description} -\end{comment} Index: doc/theses/jiada_liang_MMath/conclusion.tex =================================================================== --- doc/theses/jiada_liang_MMath/conclusion.tex (revision 11cced628083f8f93238942878f2ae83b1267af1) +++ doc/theses/jiada_liang_MMath/conclusion.tex (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) @@ -13,5 +13,5 @@ Enumeration traits define the meaning of an enumeration, allowing functions to be written that work on any enumeration, such as the reading and printing an enumeration. Using advanced duck typing, existing C enumerations can be extended so they work with all of the enumeration features, providing for legacy C code to be moved forward into the modern \CFA programming domain. -Finally, I expanded the \CFA project's test suite with multiple enumeration features tests with respect to implicit conversions, control structures, inheritance, interaction with the polymorphic types, and the features built on top of enumeration traits. +Finally, I expanded the \CFA project's test-suite with multiple enumeration features tests with respect to implicit conversions, control structures, inheritance, interaction with the polymorphic types, and the features built on top of enumeration traits. These tests ensure future \CFA work does not accidentally break the new enumeration system. @@ -21,11 +21,19 @@ \section{Future Work} +The following are ideas to improve and extend the work in this thesis. +\begin{enumerate} +\item There are still corner cases being found in the current \CFA enumeration implementation. -Fixing some of these corner cases requires changes to the \CFA resolver or extensions to \CFA, like compile-time constant-expression evaluation. +Fixing some of these corner cases requires changes to the \CFA resolver or extensions to \CFA. %, like compile-time constant-expression evaluation. When these changes are made, it should be straightforward to update the \CFA enumeration implementation to work with them. - +\item Currently, some aspects of the enumeration trait system require explicitly including the file @enum.hfa@, which can lead to problems. It should be possible to have this file included implicitly by updating the \CFA prelude. - +\item +There are multiple \CFA features being developed i parallel with enumerations. +Two closely related features are iterator and namespace. +Enumerations may have to be modified to dovetail with these features. +For example, enumerating with range loops does not align with the current iterator design, so some changes will be necessary. +\item C already provides @const@-style aliasing using the \emph{unnamed} enumerator \see{\VRef{s:TypeName}}, even if the name @enum@ is misleading (@const@ would be better). Given the existence of this form, it is conceivable to extend it with types other than @int@. @@ -42,19 +50,21 @@ enum( wchar_t * ) { Jack = L"John" }; \end{cfa} -There are several new features have been proposed or are developing in parallel with enumerations. -Two closely related features are iterator and namespace. - -Enumerating features, and range loops in particular, are currently implemented as loops unique to \CFA enumeration and do not align with the -general iterator pattern. They can be adapted to the iterator interface when it comes to maturity. - -Currently, \CFA implements a namespace feature for enumerated types only. There is recently a proposal by Andrew to -generalize the concept of namespace to other types. The enumeration scope will be revisited to follow the semantics -with other types. Also to improve the granularity of scope control, we propose the following extension: +\item +Currently enumeration scoping is all or nothing. +In some cases, it might be useful to increase the scoping granularity to individual enumerators. \begin{cfa} enum E1 { @!@A, @^@B, C }; enum E2 @!@ { @!@A, @^@B, C }; \end{cfa} -which provides a combination of scoped and unscoped enumerators. +Here, @'!'@ means the enumerator is scoped, and @'^'@ means the enumerator is unscoped. For @E1@, @A@ is scoped; @B@ and @C@ are unscoped. For @E2@, @A@, and @C@ are scoped; @B@ is unscoped. -Finding a use case is important to justify completing this extension. +Finding a use case is important to justify this extension. +\item +An extension mentioned in \VRef{s:Ada} is using @typedef@ to create an enumerator alias. +\begin{cfa} +enum(int) RGB { @Red@, @Green@, Blue }; +enum(int) Traffic_Light { @Red@, Yellow, @Green@ }; +typedef RGB.Red OtherRed; // alias +\end{cfa} +\end{enumerate} Index: doc/theses/jiada_liang_MMath/intro.tex =================================================================== --- doc/theses/jiada_liang_MMath/intro.tex (revision 11cced628083f8f93238942878f2ae83b1267af1) +++ doc/theses/jiada_liang_MMath/intro.tex (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) @@ -105,5 +105,5 @@ Hence, the term \emph{enumeration} can be confusing and misunderstood. Furthermore, some languages conjoin the enumeration with other type features, making it difficult to tease apart which feature is being used. -This section discusses some language features that are sometimes called enumeration but do not provide all enumeration aspects. +This section discusses some language features that are sometimes called an enumeration but do not provide all enumeration aspects. Index: doc/theses/jiada_liang_MMath/relatedwork.tex =================================================================== --- doc/theses/jiada_liang_MMath/relatedwork.tex (revision 11cced628083f8f93238942878f2ae83b1267af1) +++ doc/theses/jiada_liang_MMath/relatedwork.tex (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) @@ -18,5 +18,5 @@ \end{comment} -Enumeration-like features exist in many popular programming languages, both past and present, \eg Pascal~\cite{Pascal}, Ada~\cite{Ada}, \Csharp~\cite{Csharp}, OCaml~\cite{OCaml} \CC, Go~\cite{Go}, Haskell~\cite{Haskell}, Java~\cite{Java}, Rust~\cite{Rust}, Swift~\cite{Swift}, Python~\cite{Python}. +Enumeration-like features exist in many popular programming languages, both past and present, \eg Pascal~\cite{Pascal}, Ada~\cite{Ada}, \Csharp~\cite{Csharp}, OCaml~\cite{OCaml} \CC, Go~\cite{Go}, Haskell~\cite{Haskell} \see{discussion in \VRef{s:AlgebraicDataType}}, Java~\cite{Java}, Rust~\cite{Rust}, Swift~\cite{Swift}, Python~\cite{Python}. Among these languages, there is a large set of overlapping features, but each language has its own unique extensions and restrictions. @@ -33,5 +33,5 @@ The type of each constant name (enumerator) is inferred from the constant-expression type. -Some dialects of Pascal introduced the enumeration type characterized by a set of ordered, unscoped identifiers (enumerators), which are not overloadable.\footnote{% +Pascal introduced the enumeration type characterized by a set of ordered, unscoped identifiers (enumerators), which are not overloadable.\footnote{% Pascal is \emph{case-insensitive} so identifiers may appear in multiple forms and still be the same, \eg \lstinline{Mon}, \lstinline{moN}, and \lstinline{MON} (a questionable design decision).} \begin{pascal} @@ -56,12 +56,12 @@ \end{cquote} -Pascal provides \emph{consecutive} subtyping of an enumeration using subrange type. +Pascal provides \emph{consecutive} subsetting of an enumeration using a subrange type. \begin{pascal} type Week = ( Mon, Tue, Wed, Thu, Fri, Sat, Sun ); - Weekday = @Mon..Fri@; - Weekend = @Sat..Sun@; + Weekday = @Mon..Fri@; { subtype } + Weekend = @Sat..Sun@; var day : Week; - wday : Weekday; - wend : Weekend; + wday : Weekday; + wend : Weekend; \end{pascal} Hence, the ordering of the enumerators is crucial to provide the necessary ranges. @@ -85,13 +85,15 @@ \begin{tabular}{@{}ll@{}} \begin{pascal} +day := Mon; if @day@ = wday then Writeln( day ); if @day@ <= Fri then Writeln( 'weekday'); - - +Mon +weekday \end{pascal} & \begin{pascal} + case @day@ of Mon..Fri : @@ -100,4 +102,5 @@ Writeln( 'weekend') end; +weekday \end{pascal} \end{tabular} @@ -107,19 +110,17 @@ \begin{tabular}{@{}ll@{}} \begin{pascal} -day := Mon; -while day <= Sat do begin +while day <= Sun do begin Write( day, ' ' ); day := succ( day ); end; -Mon Tue Wed Thu Fri Sat +Mon Tue Wed Thu Fri Sat Sun \end{pascal} & \begin{pascal} - -for day := Mon to Sat do begin +for day := Mon to Sun do begin Write( day, ' ' ); end; -Mon Tue Wed Thu Fri Sat +Mon Tue Wed Thu Fri Sat Sun \end{pascal} \end{tabular} @@ -150,5 +151,5 @@ The underlying type is an implementation-defined integral type large enough to hold all enumerated values; it does not have to be the smallest possible type. -The integral size can be explicitly specified using compiler directive \$@PACKENUM@~$N$, where $N$ is the number of bytes, \eg: +The integral size can be explicitly specified using compiler directive @$PACKENUM@~$N$, where $N$ is the number of bytes, \eg: \begin{pascal} Type @{$\color{red}\$$PACKENUM 1}@ SmallEnum = ( one, two, three ); @@ -160,4 +161,5 @@ \section{Ada} +\label{s:Ada} An Ada enumeration type is a set of ordered, unscoped identifiers (enumerators) bound to \emph{unique} \newterm{literals}.\footnote{% @@ -167,5 +169,5 @@ \end{ada} Object initialization and assignment are restricted to the enumerators of this type. -While Ada enumerators are unscoped, Ada enumerators are overloadable. +While Ada enumerators are unscoped, like C, Ada enumerators are overloadable. \begin{ada} type RGB is ( @Red@, @Green@, Blue ); @@ -173,5 +175,5 @@ \end{ada} Like \CFA, Ada uses a type-resolution algorithm, including the left-hand side of the assignment, to disambiguate among overloaded identifiers. -\VRef[Figure]{f:AdaEnumeration} shows how ambiguity is handled using a cast, \ie \lstinline[language=ada]{RGB'(Red)}. +\VRef[Figure]{f:AdaEnumeration} shows how ambiguity is handled using a cast, \eg \lstinline[language=ada]{RGB'(Red)}. \begin{figure} @@ -194,5 +196,5 @@ \end{ada} \caption{Ada Enumeration Overload Resolution} -\label{f:AdaEnumeration} +\label{f:AdaEnumeration} \end{figure} @@ -201,5 +203,5 @@ \begin{ada} type Week is ( Mon, Tue, Wed, Thu, Fri, Sat, Sun ); -for Week use ( Mon => 0, Tue => 1, Wed => 2, Thu => @10@, Fri => 11, Sat => 14, Sun => 15 ); + for Week use ( Mon => 0, Tue => 1, Wed => 2, Thu => @10@, Fri => 11, Sat => 14, Sun => 15 ); \end{ada} The enumeration operators are the equality and relational operators, @=@, @/=@, @<@, @<=@, @=@, @/=@, @>=@, @>@, where the ordering relationship is given implicitly by the sequence of ascending enumerators. @@ -259,7 +261,7 @@ if @Flag@ then ... -- conditional \end{ada} -Since only types derived from @Boolean@ can be conditional, @Boolean@ is essentially a built-in type. - -Ada provides \emph{consecutive} subtyping of an enumeration using \lstinline[language=ada]{range}. +Since only types derived from @Boolean@ can be conditional, @Boolean@ is essentially a builtin type. + +Ada provides \emph{consecutive} subsetting of an enumeration using \lstinline[language=ada]{range}. \begin{ada} type Week is ( Mon, Tue, Wed, Thu, Fri, Sat, Sun ); @@ -351,36 +353,23 @@ whereas C @const@ declarations without @static@ are marked @R@. -The following \CC non-backwards compatible changes are made \see{\cite[\S~7.2]{ANSI98:c++}}. -\begin{cquote} -Change: \CC objects of enumeration type can only be assigned values of the same enumeration type. -In C, objects of enumeration type can be assigned values of any integral type. \\ -Example: -\begin{c++} -enum color { red, blue, green }; -color c = 1; $\C{// valid C, invalid c++}$ -\end{c++} -\textbf{Rationale}: The type-safe nature of \CC. \\ -\textbf{Effect on original feature}: Deletion of semantically well-defined feature. \\ -\textbf{Difficulty of converting}: Syntactic transformation. (The type error produced by the assignment can be automatically corrected by applying an explicit cast.) \\ -\textbf{How widely used}: Common. -\end{cquote} - -\begin{cquote} -Change: In \CC, the type of an enumerator is its enumeration. -In C, the type of an enumerator is @int@. \\ +The following \CC non-backward compatible change is made~\cite[C.1.5.7.2]{C++}, plus the safe-assignment change shown in~\VRef{s:TypeSafety}. +\begin{description}[parsep=0pt] +\item[Change:] In \CC, the type of an enumerator is its enumeration. +In C, the type of an enumerator is @int@. Example: \begin{c++} enum e { A }; sizeof(A) == sizeof(int) $\C{// in C}$ -sizeof(A) == sizeof(e) $\C{// in c++}$ +sizeof(A) == sizeof(e) $\C{// in \CC}$ /* and sizeof(int) is not necessary equal to sizeof(e) */ \end{c++} -\textbf{Rationale}: In \CC, an enumeration is a distinct type. \\ -\textbf{Effect on original feature}: Change to semantics of well-defined feature. \\ -\textbf{Difficulty of converting}: Semantic transformation. \\ -\textbf{How widely used}: Seldom. The only time this affects existing C code is when the size of an enumerator is taken. +\item[Rationale:] In \CC, an enumeration is a distinct type. +\item[Effect on original feature:] Change to semantics of well-defined feature. +\item[Difficulty of converting:] Semantic transformation. +\item[How widely used:] Seldom. The only time this affects existing C code is when the size of an enumerator is taken. Taking the size of an enumerator is not a common C coding practice. -\end{cquote} +\end{description} Hence, the values in a \CC enumeration can only be its enumerators (without a cast). + While the storage size of an enumerator is up to the compiler, there is still an implicit cast to @int@. \begin{c++} @@ -438,7 +427,5 @@ \end{tabular} \end{cquote} -% However, there is no mechanism to iterate through an enumeration without an unsafe cast and it does not understand the enumerator values. -\CC enumerators are not relational: the only comparator defined for \CC is the value comparison. The define order of enumerator has no -impact on its behaviour. As a consequence, \CC has no meaningful enumerating mechanism. +However, there is no mechanism to iterate through an enumeration without an unsafe cast and it does not understand the enumerator values. \begin{c++} enum Week { Mon, Tue, Wed, Thu = 10, Fri, Sat, Sun }; @@ -446,9 +433,8 @@ 0 1 2 @3 4 5 6 7 8 9@ 10 11 12 13 \end{c++} -An approximation of enumerating an enum in \CC is to use the last enumerator value as a range. But it inevitably -fails, the enumeration value does not assemble auto-initialization. +As a consequence, there is no meaningful enumerating mechanism. An enumeration type cannot declare an array dimension but an enumerator can be used as a subscript. -There is no mechanism to subtype or inherit from an enumeration. +There is no mechanism to subset or inherit from an enumeration. @@ -465,5 +451,5 @@ enum RGB { Red, Green, Blue } \end{csharp} -The default underlying integral type is @int@ (no @char@), with auto-incrementing and implicit/explicit initialization. +The default underlying integral type is @int@, with auto-incrementing and implicit/explicit initialization. A method cannot be defined in an enumeration type (extension methods are possible). There is an explicit bidirectional conversion between an enumeration and its integral type, and an implicit conversion to the enumerator label in display contexts. @@ -482,8 +468,7 @@ Enumerators have no defined positional meaning. \begin{csharp} -day = day++ - 5; $\C{// unsafe}$ +day = day++ - 5; $\C{// value manipulation}$ day = day & day; \end{csharp} - \begin{csharp} for ( Week d = Mon; d <= Sun; @d += 1@ ) { @@ -492,4 +477,5 @@ Mon Tue Wed @3 4 5 6 7 8 9@ Thu Fri Sat Sun \end{csharp} +As a consequence, there is no direct meaningful enumerating mechanism. An enumeration can be used in the @if@ and @switch@ statements. @@ -519,5 +505,5 @@ \end{cquote} -As a compliment, \Csharp's Enum library has @Enum.GetValues@ pseudo-method that retrieves an array of the enumeration constants for looping over an enumeration type or variable (expensive operation). +To indirectly enumerate, \Csharp's Enum library has @Enum.GetValues@, a pseudo-method that retrieves an array of the enumeration constants for looping over an enumeration type or variable (expensive operation). \begin{csharp} foreach ( Week d in @Enum.GetValues@( typeof(Week) ) ) { @@ -526,8 +512,8 @@ Mon 0, Tue 1, Wed 2, Thu 10, Fri 11, Sat 12, Sun 13, \end{csharp} -Hence, enumerating is not supplied directly by the enumeration, but indirectly through another enumerable type, array. +Hence, enumerating is not supplied directly by the enumeration, but indirectly through the enumerable array type. An enumeration type cannot declare an array dimension but an enumerator can be used as a subscript. -There is no mechanism to subtype or inherit from an enumeration. +There is no mechanism to subset or inherit from an enumeration. The @Flags@ attribute creates a bit-flags enumeration, making bitwise operators @&@, @|@, @~@ (complement), @^@ (xor) sensible. @@ -543,8 +529,8 @@ -\section{Golang} -\label{s:Golang} - -Golang has a no enumeration. +\section{Go} +\label{s:Go} + +Go has a no enumeration. It has @const@ aliasing declarations, similar to \CC \see{\VRef{s:C++RelatedWork}}, for basic types with type inferencing and static initialization (constant expression). \begin{Go} @@ -555,7 +541,7 @@ const V = 3.1; const W = 3.1; \end{Go} -Since these declarations are immutable variables, they are unscoped, and Golang has no overloading. - -Golang provides an enumeration-like feature to group together @const@ declaration into a block and introduces a form of auto-initialization. +Since these declarations are immutable variables, they are unscoped and Go has no overloading. + +Go provides an enumeration-like feature to group together @const@ declaration into a block and introduces a form of auto-initialization. \begin{Go} const ( R = 0; G; B ) $\C{// implicit initialization: 0 0 0}$ @@ -584,11 +570,11 @@ \begin{Go} const ( Mon = iota; Tue; Wed; // 0, 1, 2 - @Thu = 10@; Fri; Sat; Sun = itoa ) // 10, 10, 10, 6 + @Thu = 10@; Fri; Sat; @Sun = itoa@ ) $\C{// 10, 10, 10, {\color{red}6}}$ \end{Go} -Auto-initialization from \lstinline[language=Go]{iota} is restarted and \lstinline[language=Go]{iota} reinitialized with an expression containing as most \emph{one} \lstinline[language=Go]{iota}. +Auto-initialization from \lstinline[language=Go]{iota} is restarted and \lstinline[language=Go]{iota} reinitialized with an expression containing at most \emph{one} \lstinline[language=Go]{iota}. \begin{Go} const ( V1 = iota; V2; @V3 = 7;@ V4 = @iota@ + 1; V5 ) // 0 1 7 4 5 const ( Mon = iota; Tue; Wed; // 0, 1, 2 - @Thu = 10;@ Fri = @iota - Wed + Thu - 1@; Sat; Sun ) // 10, 11, 12, 13 + @Thu = 10;@ Fri = @iota@ - Wed + Thu - 1; Sat; Sun ) // 10, 11, 12, 13 \end{Go} Here, @V4@ and @Fri@ restart auto-incrementing from \lstinline[language=Go]{iota} and reset \lstinline[language=Go]{iota} to 4 and 11, respectively, because of the initialization expressions containing \lstinline[language=Go]{iota}. @@ -635,7 +621,5 @@ A basic Java enumeration is an opaque enumeration, where the enumerators are constants. \begin{Java} -enum Week { - Mon, Tue, Wed, Thu, Fri, Sat, Sun; -} +enum Week { Mon, Tue, Wed, Thu, Fri, Sat, Sun; } Week day = Week.Sat; \end{Java} @@ -643,5 +627,5 @@ The value of an enumeration instance is restricted to its enumerators. -The position (ordinal) and label are accessible but there is no value. +The position (ordinal) and label (name) are accessible but there is no value property. \begin{Java} System.out.println( day.!ordinal()! + " " + !day! + " " + day.!name()! ); @@ -649,5 +633,5 @@ \end{Java} Since @day@ has no value, it prints its label (name). -The member @valueOf@ is the inverse of @name@, converting a string to an enumerator. +The member @valueOf@ is the inverse of @name@ converting a string to an enumerator. \begin{Java} day = Week.valueOf( "Wed" ); @@ -839,5 +823,5 @@ \end{c++} An enumeration type cannot declare an array dimension nor as a subscript. -There is no mechanism to subtype or inherit from an enumeration. +There is no mechanism to subset or inherit from an enumeration. @@ -888,11 +872,9 @@ \end{tabular} \end{cquote} -(Note, after an @adt@'s type is know, the enumerator is inferred without qualification, \eg @.I(3)@.) +Note, after an @adt@'s type is know, the enumerator is inferred without qualification, \eg @.I(3)@. An enumeration is created when \emph{all} the enumerators are unit-type, which is like a scoped, opaque enumeration. \begin{swift} -enum Week { - case Mon, Tue, Wed, Thu, Fri, Sat, Sun // unit-type -}; +enum Week { case Mon, Tue, Wed, Thu, Fri, Sat, Sun }; // unit-type var week : Week = @Week.Mon@; \end{swift} @@ -921,8 +903,8 @@ An enumeration can have methods. \begin{swift} -enum Week: Comparable { +enum Week: @Comparable@ { case Mon, Tue, Wed, Thu, Fri, Sat, Sun // unit-type - func @isWeekday() -> Bool@ { return self <= .Fri } // method - func @isWeekend() -> Bool@ { return .Sat <= self } // method + func @isWeekday() -> Bool@ { return self <= .Fri } // methods + func @isWeekend() -> Bool@ { return .Sat <= self } }; \end{swift} @@ -948,5 +930,4 @@ \end{tabular} \end{cquote} - Enumerating is accomplished by inheriting from @CaseIterable@ without any associated values. \begin{swift} @@ -954,12 +935,7 @@ case Mon, Tue, Wed, Thu, Fri, Sat, Sun // unit-type }; -var weeki : Week = Week.Mon; -if weeki <= .Fri { - print( "weekday" ); -} for day in Week@.allCases@ { print( day, terminator:" " ) } -weekday Mon Tue Wed Thu Fri Sat Sun \end{swift} @@ -1011,7 +987,7 @@ % https://docs.python.org/3/howto/enum.html -Python is a dynamically typed reflexive programming language with multiple incompatible versions. +Python is a dynamically-typed reflexive programming language with multiple incompatible versions. The generality of the language makes it possible to extend existing or build new language features. -As a result, discussing Python enumerations is a moving target because if a feature does not exist, it can often be created with varying levels of complexity within the language. +As a result, discussing Python enumerations is a moving target, because if a feature does not exist, it can often be created with varying levels of complexity within the language. Therefore, the following discussion is (mostly) restricted to the core enumeration features in Python 3.13. @@ -1030,5 +1006,5 @@ Mon : 1 Tue : 2 Wed : 3 Thu : 10 Fri : !11! Sat : 4 Sun : !12! \end{python} -where @auto@ increments by 1 from the previous @auto@ value \see{Golang \lstinline[language=Go]{iota}, \VRef{s:Golang}}. +where @auto@ increments by 1 from the previous @auto@ value \see{Go \lstinline[language=Go]{iota}, \VRef{s:Go}}. @auto@ is controlled by member @_generate_next_value_()@, which can be overridden: \begin{python} @@ -1096,7 +1072,7 @@ class Week(!OrderedEnum!): Mon = 1; Tue = 2; Wed = 3; Thu = 4; Fri = 5; Sat = 6; Sun = 7 - def !isWeekday(self)!: # method + def !isWeekday(self)!: # methods return Week(self.value) !<=! Week.Fri - def !isWeekend(self)!: # method + def !isWeekend(self)!: return Week.Sat !<=! Week(self.value) \end{python} @@ -1246,12 +1222,12 @@ & \begin{ocaml} - - - - - 3 3.5 3 5 + + + + + \end{ocaml} \end{tabular} @@ -1298,11 +1274,10 @@ As seen, a type tag can be used in the @if@ and \lstinline[language=ocaml]{match} statements, where \lstinline[language=ocaml]{match} must be exhaustive or have a default case. -% Enumerating is accomplished by deriving from @enumerate@. -OCaml enumerators have an ordering following the definition order, but they are not enumerable. -To iterate over all enumerators, an OCaml type needs to derive the @enumerate@ preprocessor, which appends a list of all enumerators to the program -abstract syntax tree (AST). The list of values may not persist in the defined ordering. Given that it needs tools that are outside of the native language to facilitate, -we claim it has no capability of enumerating. - -Enumeration subtyping is allowed but inheritance is restricted to classes not types. +While OCaml enumerators have an ordering following the definition order, they are not enumerable. +To iterate over all enumerators, an OCaml type needs to derive from the @enumerate@ preprocessor, which appends a list of all enumerators to the program abstract syntax tree (AST). +However, the list of values may not persist in the defined ordering. +As a consequence, there is no meaningful enumerating mechanism. + +Enumeration subsetting is allowed but inheritance is restricted to classes not types. \begin{ocaml} type weekday = Mon | Tue | Wed | Thu | Fri @@ -1557,7 +1532,7 @@ unique values & \CM & \CM & & & & & & \CM & & & & \\ \hline -auto-init & \CM & @all or none@ & \CM & & & \CM & \CM & \CM & \CM & \CM & \CM & \CM \\ +auto-init & \CM & all or none & \CM & & & \CM & \CM & \CM & \CM & \CM & \CM & \CM \\ \hline -(un)Scoped & U & U & S & S & S & U & S & S & S & U & U/S & U/S \\ +(Un)Scoped & U & U & S & S & S & U & S & S & S & U & U/S & U/S \\ \hline overload & & \CM & & & & & & & & & & \CM \\ @@ -1574,17 +1549,18 @@ \begin{enumerate} -\item Opaque: Opaque enums' enumerator cannot be used as its underlying representation or being implemented in terms of ADT. -\item Typed: The type of value. H: heterogeneous type; values from the same enum need not be the same type. -U: uni-type; value must have the same type. -\item Safe: An enumeration variable can only hold a value from its defined enumerators. -\item Posn ordered: enumerators have defined ordering based on enumerator declaration order. -It is implied position ordered if its enumerator value must be strictly increasingly ordered. -\item Unique value: enumerators must have a unique value. -\item Auto-init: Values are auto-initializable by language specification, often being the "+1" of the predecessor. -\item (Un)Scoped: U: unscoped enumerators and did not need qualification; S: Scoped enumerators and requires qualification. -\item Overload: An enumerator label can be used without type qualification in a context where multiple enumerations have defined the label. -\item Loop: Enumerate enum members without the need to convert an enumeration to another data structure -\item Arr. dim: An enumeration can be used directly as an array dimension, and enumerators can be mapped to an array element (not a conversion to integer type). -\item Subset: Name a subset of enumerators as a new type. -\item Superset: Create a new enumeration that contains all enumerators from pre-defined enumerations. +\item opaque: an enumerator cannot be used as its underlying representation or implemented in terms of an ADT. +\item typed: H $\Rightarrow$ heterogeneous, \ie enumerator values may be different types. \\ +U $\Rightarrow$ homogenous, \ie enumerator values have the same type. +\item safety: An enumeration variable can only hold a value from its defined enumerators. +\item posn ordered: enumerators have defined ordering based on enumerator declaration order. +Position ordered is implied if the enumerator values must be strictly increasingly. +\item unique value: enumerators must have a unique value. +\item auto-init: Values are auto-initializable by language specification, often being "+1" of the predecessor. +\item (Un)Scoped: U $\Rightarrow$ enumerators are projected into the containing scope. +S $\Rightarrow$ enumerators are contained in the enumeration scope and require qualification. +\item overload: An enumerator label can be used without type qualification in a context where multiple enumerations have defined the label. +\item loop: Enumerate without the need to convert an enumeration to another data structure. +\item arr. dim: An enumeration can be used directly as an array dimension, and enumerators can be mapped to an array element (not a conversion to integer type). +\item subset: Name a subset of enumerators as a new type. +\item superset: Create a new enumeration that contains all enumerators from pre-defined enumerations. \end{enumerate} Index: doc/theses/jiada_liang_MMath/uw-ethesis-frontpgs.tex =================================================================== --- doc/theses/jiada_liang_MMath/uw-ethesis-frontpgs.tex (revision 11cced628083f8f93238942878f2ae83b1267af1) +++ doc/theses/jiada_liang_MMath/uw-ethesis-frontpgs.tex (revision c1c0efdb714bbffa4bd0fefe0972a773e215c475) @@ -145,5 +145,5 @@ The \CFA (C-for-all) programming language is an evolutionary refinement of the C programming language. One of its distinctive features is a parametric-polymorphic generic type. -However, legacy data types from C, such as enumerations, do not adapt well to the \CFA generic type system. +However, legacy data types from C, such as enumerations, do not adapt well to the \CFA generic type-system. This thesis extends the simple and unsafe enumeration type in the C programming language into a complex and safe enumeration type in the \CFA programming-language, while maintaining backwards compatibility with C.