Changeset 4da9142 for doc/theses

Timestamp:

Apr 18, 2024, 10:23:34 PM (8 months ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master

Children:

2b6db03

Parents:

c148966

Message:

more proofreading on enumerations

Location:

doc/theses/jiada_liang_MMath

Files:

• CFAenum.tex (modified) (1 diff)
• background.tex (modified) (1 diff)
• intro.tex (modified) (6 diffs)
• relatedwork.tex (modified) (28 diffs)

doc/theses/jiada_liang_MMath/CFAenum.tex

@@ -137 +137 @@
 \section{Pure Enumerators}
 
-An empty enumerator type, @enum()@, implies the enumerators are pure symbols without values but set properties;
+An empty enumerator type, @enum()@, implies the enumerators are opaque symbols without values but set properties;
 hence, there is no default conversion to @int@. 
 

doc/theses/jiada_liang_MMath/background.tex

@@ -48 +48 @@
 
 \section{C Enumeration}
+\label{s:CEnumeration}
 
-The C enumeration has the following syntax and semantics.
+The C enumeration has the following syntax~\cite[\S~6.7.2.2]{C11}.
+\begin{clang}[identifierstyle=\linespread{0.9}\it]
+$\it enum$-specifier:
+        enum identifier$\(_{opt}\)$ { enumerator-list }
+        enum identifier$\(_{opt}\)$ { enumerator-list , }
+        enum identifier
+enumerator-list:
+        enumerator
+        enumerator-list , enumerator
+enumerator:
+        enumeration-constant
+        enumeration-constant = constant-expression
+\end{clang}
+The terms \emph{enumeration} and \emph{enumerator} used in this work \see{\VRef{s:Terminology}} come from the grammar.
+The C enumeration semantics is discussed using examples.
+
+An unnamed enumeration is used to provide secondary renaming, like a @const@ declaration in other languages.
+\begin{clang}
+enum { Size = 20, Pi = 3.14159 };   // unnamed enumeration $\(\Rightarrow\)$ no ordering
+\end{clang}
+This declaration form is not an enumeration even though it is declared using an @enum@ because it has none of the following enumeration properties.
+
+A \emph{named} enumeration type is an actual enumeration.
 \begin{clang}
 enum Weekday { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun, };

doc/theses/jiada_liang_MMath/intro.tex

@@ -1 +1 @@
 \chapter{Introduction}
 
-All types in a programming language must have a set of constants, and these constants have \Newterm{primary names}, \eg integral types have constants @-1@, @17@, @12345@, \etc.
-Constants can be overloaded among types, \eg @0@ is a null pointer for all pointer types, and the value zero for integral and floating-point types.
+All types in a programming language must have a set of constants, and these constants have \Newterm{primary names}, \eg integral types have constants @-1@, @17@, @0xff@, floating-point types have constants @5.3@, @2.3E-5@, @0xff.ffp0@, character types have constants @'a'@, @"abc\n"@, \mbox{\lstinline{u8"}\texttt{\guillemotleft{na\"{i}ve}\guillemotright}\lstinline{"}}, \etc.
+Con\-stants can be overloaded among types, \eg @0@ is a null pointer for all pointer types, and the value zero for integral and floating-point types.
+(In \CFA, the primary constants @0@ and @1@ can be overloaded for any type.)
 Hence, each primary constant has a symbolic name referring to its internal representation, and these names are dictated by language syntax related to types.
 In theory, there are an infinite set of primary names per type.
 
-\Newterm{Secondary naming} is a common practice in mathematics and engineering, \eg $\pi$, $\tau$ (2$\pi$), $\phi$ (golden ratio), MHz (1E6), and in general situations, \eg specific times (noon, New Years), cities (Big Apple), flowers (Lily), \etc.
+\Newterm{Secondary naming} is a common practice in mathematics, engineering and computer science, \eg $\pi$, $\tau$ (2$\pi$), $\phi$ (golden ratio), MB (mega byte, 1E6), and in general situations, \eg specific times (noon, New Years), cities (Big Apple), flowers (Lily), \etc.
 Many programming languages capture this important software-engineering capability through a mechanism called \Newterm{constant} or \Newterm{literal} naming, where a secondary name is aliased to a primary name.
-In some cases, secondary naming is \Newterm{pure}, where the matching internal representation can be chosen arbitrarily, and only equality operations are available, \eg @O_RDONLY@, @O_WRONLY@, @O_CREAT@, @O_TRUNC@, @O_APPEND@.
-(The names the thing.)
+Its common purpose is to eliminate duplication of the primary constant throughout a program.
+For example, the secondary name replaces its primary name, thereafter changing the binding of the secondary to primary name automatically distributes the rebinding throughout the program.
+In some cases, secondary naming is \Newterm{opaque}, where the matching internal representation can be chosen arbitrarily, and only equality operations are available, \eg @O_RDONLY@, @O_WRONLY@, @O_CREAT@, @O_TRUNC@, @O_APPEND@.
 Because a secondary name is a constant, it cannot appear in a mutable context, \eg \mbox{$\pi$ \lstinline{= 42}} is meaningless, and a constant has no address, \ie it is an \Newterm{rvalue}\footnote{
 The term rvalue defines an expression that can only appear on the right-hand side of an assignment expression.}.
@@ -18 +20 @@
 enumerate (verb, transitive).
 To count, ascertain the number of;
-\emph{more
-usually, to mention (a number of things or persons) separately, as if for the
-purpose of counting};
-to specify as in a list or catalogue.~\cite{OED}
+more usually, to mention (a number of things or persons) separately, as if for the purpose of counting;
+to specify as in a list or catalogue.~\cite{OEDenumerate}
 \end{quote}
-Within an enumeration set, the enumeration names must be unique, and instances of an enumerated type are restricted to hold only the secondary names.
+Within an enumeration set, the enumeration names must be unique, and instances of an enumerated type are \emph{often} restricted to hold only the secondary names.
 It is possible to enumerate among set names without having an ordering among the set elements.
 For example, the week, the weekdays, the weekend, and every second day of the week.
@@ -29 +29 @@
 for ( cursor in Mon, Tue, Wed, Thu, Fri, Sat, Sun } ... $\C[3.75in]{// week}$
 for ( cursor in Mon, Tue, Wed, Thu, Fri } ...   $\C{// weekday}$
-for ( cursor in Thu, Fri } ...                                  $\C{// weekend}$
+for ( cursor in Sat, Sun } ...                                  $\C{// weekend}$
 for ( cursor in Mon, Wed, Fri, Sun } ...                $\C{// every second day of week}\CRT$
 \end{cfa}
-This independence from internal representation allows multiple names to have the same representation (eight note, quaver), giving synonyms.
+This independence from internal representation allows multiple names to have the same representation (eighth note, quaver), giving synonyms.
 A set can have a partial or total ordering, making it possible to compare set elements, \eg Monday is before Friday and Friday is after.
 Ordering allows iterating among the enumeration set using relational operators and advancement, \eg
@@ -38 +38 @@
 for ( cursor = Monday; cursor @<=@ Friday; cursor = @succ@( cursor ) ) ...
 \end{cfa}
-Here the internal representations for the secondary names are \emph{generated} rather than listing a subset of names.
+Here the internal representations for the secondary names are logically \emph{generated} rather than listing a subset of names.
+
+Hence, the fundamental aspects of an enumeration are:
+\begin{enumerate}
+\item
+It defines a type from which instants can be generated.
+\item
+The type lists a finite set of secondary names, which become its primary constants.
+This differentiates an enumeration from general types with an infinite number of primary constants.
+\item
+An enumeration's secondary names represent constants, which follows from their binding (aliasing) to primary names, which are constants.
+\item
+For safety, an enumeration instance is restricted to hold only its type's secondary names.
+\item
+There is a mechanism for \emph{enumerating} over the secondary names, where the ordering can be implicit from the type, explicitly listed, or generated arithmetically.
+\end{enumerate}
 
 
 \section{Terminology}
-
-The term \Newterm{enumeration} defines the set of secondary names, and the term \Newterm{enumerator} represents an arbitrary secondary name.
+\label{s:Terminology}
+
+The term \Newterm{enumeration} defines a type with a set of secondary names, and the term \Newterm{enumerator} represents an arbitrary secondary name \see{\VRef{s:CEnumeration}}.
 As well, an enumerated type has three fundamental properties, \Newterm{label}, \Newterm{order}, and \Newterm{value}.
 \begin{cquote}
@@ -72 +88 @@
 \section{Motivation}
 
-Some programming languages only provide secondary renaming, which can be simulated by an enumeration without ordering.
-\begin{cfa}
-const Size = 20, Pi = 3.14159;
-enum { Size = 20, Pi = 3.14159 };   // unnamed enumeration $\(\Rightarrow\)$ no ordering
-\end{cfa}
-In both cases, it is possible to compare the secondary names, \eg @Size < Pi@, if that is meaningful;
-however, without an enumeration type-name, it is impossible to create an iterator cursor.
-
-Secondary renaming can similate an enumeration, but with extra effort.
+Some programming languages only provide direct secondary renaming.
+\begin{cfa}
+const Size = 20, Pi = 3.14159, Name = "Jane";
+\end{cfa}
+Here, it is possible to compare the secondary names, \eg @Size < Pi@, if that is meaningful.
+
+Secondary renaming can simulate an enumeration, but with extra effort.
 \begin{cfa}
 const Mon = 1, Tue = 2, Wed = 3, Thu = 4, Fri = 5, Sat = 6, Sun = 7;
 \end{cfa}
-Furthermore, reordering the enumerators requires manual renumbering.
+Any reordering of the enumerators requires manual renumbering.
 \begin{cfa}
 const Sun = 1, Mon = 2, Tue = 3, Wed = 4, Thu = 5, Fri = 6, Sat = 7;
 \end{cfa}
-Finally, there is no common type to create a type-checked instance or iterator cursor.
-Hence, there is only a weak equivalence between secondary naming and enumerations, justifying the enumeration type in a programming language.
-
-A variant (algebraic) type is often promoted as a kind of enumeration, \ie a varient type can simulate an enumeration.
-A variant type is a tagged-union, where the possible types may be heterogeneous.
-\begin{cfa}
+Finally, there is no type to create a type-checked instance or iterator cursor.
+Hence, there is only a weak equivalence between secondary naming and enumerations, justifying a seperate enumeration type in a programming language.
+
+A variant (algebraic) type is often promoted as a kind of enumeration, \ie a variant type can simulate an enumeration.
+Fundamentally, a variant type is a tagged-union, where the tag is normally opaque and the types are usually heterogeneous.
+\begin{cfa}[morekeywords={variant}]
 @variant@ Variant {
         @int tag;@  // optional/implicit: 0 => int, 1 => double, 2 => S
@@ -103 +117 @@
 };
 \end{cfa}
-Crucially, the union implies instance storage is shared by all of the variant types.
-Hence, a variant is dynamically typed, as in a dynamic-typed programming-language, but the set of types is statically bound, similar to some aspects of dynamic gradual-typing~\cite{Gradual Typing}.
-Knowing which type is in a variant instance is crucial for correctness.
-Occasionally, it is possible to statically determine all regions where each variant type is used, so a tag and runtime checking is unnecessary;
-otherwise, a tag is required to denote the particular type in the variant and the tag checked at runtime using some form of type pattern-matching.
-
-The tag can be implicitly set by the compiler on assignment, or explicitly set by the program\-mer.
-Type pattern-matching is then used to dynamically test the tag and branch to a section of code to safely manipulate the value, \eg:
+Crucially, the union implies instance storage is shared by all the variant types, and therefore, before a variant type can be used in a statically-typed expression, it must be dynamically discriminated to its current contained type.
+Hence, knowing which type is in a variant instance is crucial for correctness.
+Occasionally, it is possible to statically determine all regions where each variant type is used, so a tag and runtime checking is unnecessary.
+Otherwise, a tag is required to denote the particular type in the variant, and the tag is discriminated at runtime using some form of type pattern-matching, after which the value can be used in a statically-typed expression.
+
+A less frequent variant case is multiple variants with the same type, which normally requires explicit naming of the tag to disambiguate among the common types.
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
+\begin{cfa}[morekeywords={variant}]
+variant VariantCT {
+        case @car@: int i;  // explicitly typed
+        case @boat@: int i;
+        case @bridge@: int i;
+};
+\end{cfa}
+&
+\begin{cfa}[morekeywords={variant}]
+variant VariantCU {
+        case @car@: ;  // empty or unit type
+        case @boat@: ;
+        case @bridge@: ;
+};
+\end{cfa}
+\end{tabular}
+\end{cquote}
+Here, the explicit tag name is used to give different meaning to the values in the common @int@ type, \eg the value 3 has different interpretations depending on the tag name.
+It is even possible to remove the type or use the empty @unit@ type (@struct unit {}@).
+It is this tag naming that is used to simulate an enumeration.
+
+Normally, the variant tag is implicitly set by the compiler based on type, but with common types, a tag name is required to resolve type ambiguity.
+\begin{cfa}
+Variant v = 3;                                                  $\C{// implicitly set tag to 0 based on type of 3}$
+VariantCT ve = boats.3;                                 $\C{// explicitly set tag to 1 using tag name}$
+\end{cfa}
+Type pattern-matching is then used to dynamically test the tag and branch to a section of statically-typed code to safely manipulate the value, \eg:
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \begin{cfa}[morekeywords={match}]
-Variant v = 3;  // implicitly set tag to 0
-@match@( v ) {    // know the type or test the tag
-        case int { /* only access i field in v */ }
-        case double { /* only access d field in v */ }
-        case S { /* only access s field in v */ }
+@match@( v ) { // know type implicitly or test tag
+        case int { /* only access i field */ }
+        case double { /* only access d field */ }
+        case S { /* only access s field */ }
 }
 \end{cfa}
-For safety, either all variant types must be listed or a @default@ case must exist with no field accesses.
-
-To simulate an enumeration with a variant, the tag is \emph{re-purposed} for either ordering or value and the variant types are omitted.
-\begin{cfa}
-variant Weekday {
-        int tag; // implicit 0 => Mon, ..., 6 => Sun
-        @case Mon;@ // no type
+&
+\begin{cfa}[morekeywords={match}]
+@match@( ve ) {
+        case car: int { /* car interpretation */ }
+        case boat: int { /* boat interpretation */ }
+        case bridge: int { /* bridge interpretation */ }
+}
+\end{cfa}
+\end{tabular}
+\end{cquote}
+For safety, some languages require all variant types to be listed or a @default@ case with no field accesses.
+
+To further strengthen the simulate for an enumeration with different values, each variant type can be a @const@ type or the tag becomes non-opaque, possibly taking advantage of the opaque auto-numbering.
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
+\begin{cfa}
+variant Week {
+        case Mon: const int = 0;
         ...
-        @case Sun;@
-};
-\end{cfa}
-The type system ensures tag setting and testing are correctly done.
-However, the enumeration operations are limited to the available tag operations, \eg pattern matching.
-\begin{cfa}
-Week week = Mon;
-if ( @dynamic_cast(Mon)@week ) ... // test tag == Mon
-\end{cfa}
+        case Sat: const int = 5;
+        case Sun: const int = 10;
+};
+\end{cfa}
+&
+\begin{cfa}
+variant Week {
+        case Mon: ;  // tag auto-numbering
+        ...
+        case Sat: ;
+        case @Sun = 10@: ; // directly set tag value
+};
+\end{cfa}
+\end{tabular}
+\end{cquote}
+Directly setting the tag implies restrictions, like unique values.
+In both cases, instances of @Week@ are @const@ (immutable).
+However, usage between these two types becomes complex.
+\begin{cfa}
+Week day = Week.Mon;  // sets value or tag depending on type
+if ( day == Week.Mon )   // dereference value or tag ?
+\end{cfa}
+Here, the dereference of @day@ should return the value of the type stored in the variant, never the tag.
+If it does return the tag, some special meaning must be given to the empty/unit type, especially if a variant contains both regular and unit types.
+
+
+In general, the enumeration simulation and the variant extensions to support it, are deviating from the normal use of a variant (union) type.
+As well, the enumeration operations are limited to the available tag operations, \eg pattern matching.
 While enumerating among tag names is possible:
 \begin{cfa}[morekeywords={in}]
-for ( cursor in Mon, Wed, Fri, Sun ) ...
-\end{cfa}
-ordering for iteration would require a \emph{magic} extension, such as a special @enum@ variant, because it has no meaning for a regular variant, \ie @int@ < @double@.
-
-However, if a special @enum@ variant allows the tags to be heterogeneously typed, ordering must fall back on case positioning, as many types have incomparable values.
-Iterating using tag ordering and heterogeneous types, also requires pattern matching.
-\begin{cfa}[morekeywords={match}]
-for ( cursor = Mon; cursor <= Fri; cursor = succ( cursor) ) {
-        match( cursor ) {
-                case Mon { /* access special type for Mon */ }
-                ...
-                case Fri { /* access special type for Fri */ }
-                default
-        }
-}
-\end{cfa}
-If the variant type is changed by adding/removing types or the loop range changes, the pattern matching must be adjusted.
-As well, if the start/stop values are dynamic, it may be impossible to statically determine if all variant types are listed. 
-
-Re-purposing the notion of enumerating into variant types is ill formed and confusing.
-Hence, there is only a weak equivalence between an enumeration and variant type, justifying the enumeration type in a programming language.
+for ( cursor in Week.Mon, Week.Wed, Week.Fri, Week.Sun ) ...
+\end{cfa}
+what is the type of @cursor@?
+If it the tag type (@int@), how is this value used?
+If it is the variant type, where is the instance variable, which only contains one value.
+Hence, either enumerating with a variant enumeration is disallowed or some unusual typing rule must be invented to make it work but only in restricted contexts.
+
+While functional programming systems regularly re-purposing variant types into enumeration types, this process seems contrived and confusing.
+A variant tag is not an enumeration, it is a discriminant among a restricted set of types stored in a storage block.
+Hence, there is only a weak equivalence between an enumeration and variant type, justifying a seperate enumeration type in a programming language.
 
 

doc/theses/jiada_liang_MMath/relatedwork.tex

@@ -53 +53 @@
 \lstnewenvironment{ada}[1][]{\lstset{language=[2005]Ada,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},literate={'}{\ttfamily'\!}1}\lstset{#1}}{}
 
-An Ada enumeration type is an ordered list of constants, called \Newterm{literals} (enumerators).
+An Ada enumeration type is a set of ordered unscoped identifiers (enumerators) bound to \emph{unique} \Newterm{literals}.\footnote{%
+Ada 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{ada}
-type RGB is ( Red, Green, Blue ); -- 3 literals (enumerators)
+type Week is ( Mon, Tue, Wed, Thu, Fri, Sat, Sun ); -- literals (enumerators)
 \end{ada}
 Object initialization and assignment are restricted to the enumerators of this type.
-Enumerators without an explicitly designated constant value are auto-initialized: from left to right, starting at zero or the next explicitly initialized constant, incrementing by 1.
-To explicitly set enumerator values, \emph{all} enumerators must be set in \emph{ascending} order, \ie there is no auto-initialization.
+While Ada enumerators are unscoped, like C, Ada enumerators are overloadable.
 \begin{ada}
-type RGB is ( Red, Green, Blue );
-@for RGB use ( Red => 10, Green => 20, Blue => 30 );@ -- ascending order
-\end{ada}
-Hence, the position, value, label tuples are:
-\begin{ada}
-(0, 10, RED)  (1, 20, GREEN)  (2, 30, BLUE) 
-\end{ada}
-Note, Ada is case-\emph{insensitive} so names may appear in multiple forms and still be the same, \eg @Red@ and @RED@ (a questionable design decision).
-
-Like C, Ada enumerators are unscoped, \ie enumerators declared inside of an enum are visible (projected) into the enclosing scope.
-The enumeration operators are the ordering operators, @=@, @<@, @<=@, @=@, @/=@, @>=@, @>@, where the ordering relationship is given implicitly by the sequence of enumerators, which is always ascending.
-
-Ada enumerators are overloadable.
-\begin{ada}
+type RGB is ( @Red@, @Green@, Blue );
 type Traffic_Light is ( @Red@, Yellow, @Green@ );
 \end{ada}
-Like \CFA, Ada uses an advanced type-resolution algorithm, including the left-hand side of assignment, to disambiguate among overloaded names.
+Like \CFA, Ada uses an advanced type-resolution algorithm, including the left-hand side of assignment, to disambiguate among overloaded identifiers.
 \VRef[Figure]{f:AdaEnumeration} shows how ambiguity is handled using a cast, \ie \lstinline[language=ada]{RGB'(Red)}.
 
@@ -102 +89 @@
 \end{figure}
 
-Ada provides an alias mechanism, \lstinline[language=ada]{renames}, for aliasing types, which is useful to shorten package names.
+Enumerators without initialization are auto-initialized from left to right, starting at zero, incrementing by 1.
+Enumerators with initialization must set \emph{all} enumerators in \emph{ascending} order, \ie there is no auto-initialization.
+\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 );
+\end{ada}
+The enumeration operators are the equality and relational operators, @=@, @/=@, @<@, @<=@, @=@, @/=@, @>=@, @>@, where the ordering relationship is given implicitly by the sequence of acsending enumerators.
+
+Ada provides an alias mechanism, \lstinline[language=ada]{renames}, for aliasing types, which is useful to shorten package identifiers.
 \begin{ada}
 OtherRed : RGB renames Red;
@@ -113 +108 @@
 There are three pairs of inverse enumeration pseudo-functions (attributes): @'Pos@ and @'Val@, @'Enum_Rep@ and @'Enum_Val@, and @'Image@ and @'Value@,
 \begin{cquote}
-\lstDeleteShortInline@
 \setlength{\tabcolsep}{15pt}
 \begin{tabular}{@{}ll@{}}
@@ -128 +122 @@
 \end{ada}
 \end{tabular}
-\lstMakeShortInline@
 \end{cquote}
 These attributes are important for IO.
@@ -138 +131 @@
 \end{ada}
 which is syntactic sugar for the label and not character literals from the predefined type @Character@.
-The purpose is strictly readability using character literals rather than names.
+The purpose is strictly readability using character literals rather than identifiers.
 \begin{ada}
 Op : Operator := '+';
@@ -171 +164 @@
 An enumeration type can be used in the Ada \lstinline[language=ada]{case} (all enumerators must appear or a default) or iterating constructs.
 \begin{cquote}
-\lstDeleteShortInline@
 \setlength{\tabcolsep}{15pt}
 \begin{tabular}{@{}ll@{}}
@@ -211 +203 @@
 \end{ada}
 \end{tabular}
-\lstMakeShortInline@
 \end{cquote}
 
@@ -229 +220 @@
 \CC has the equivalent of Pascal typed @const@ declarations \see{\VRef{s:Pascal}}, with static and dynamic initialization.
 \begin{c++}
-const auto one = 0 + 1;                                 $\C{// static intialization}$
+const auto one = 0 + 1;                                 $\C{// static initialization}$
 const auto NULL = nullptr;
 const auto PI = 3.14159;
@@ -237 +228 @@
                                 Sat = Fri + 1, Sun = Sat + 1;
 int sa[Sun];
-const auto r = random();                                $\C{// dynamic intialization}$
+const auto r = random();                                $\C{// dynamic initialization}$
 int da[r];                                                              $\C{// VLA}$
 \end{c++}
@@ -362 +353 @@
 \begin{figure}
 \centering
-\lstDeleteShortInline@
 \begin{tabular}{@{}l|l@{}}
 \multicolumn{1}{@{}c|}{non-object oriented} & \multicolumn{1}{c@{}}{object oriented} \\
@@ -414 +404 @@
 \end{csharp}
 \end{tabular}
-\lstMakeShortInline@
 \caption{\Csharp: Free Routine Versus Class Enumeration}
 \label{CsharpFreeVersusClass}
@@ -429 +418 @@
 const ( S = 0; T; USA = "USA"; U; V = 3.1; W ) $\C{// type change, implicit/explicit: 0 0 USA USA 3.1 3.1}$
 \end{Go}
-Constant names are unscoped and must be unique (no overloading).
+Constant identifiers are unscoped and must be unique (no overloading).
 The first enumerator \emph{must} be explicitly initialized;
 subsequent enumerators can be implicitly or explicitly initialized.
@@ -459 +448 @@
 Basic switch and looping are possible.
 \begin{cquote}
-\lstDeleteShortInline@
 \setlength{\tabcolsep}{15pt}
 \begin{tabular}{@{}ll@{}}
@@ -482 +470 @@
 \end{Go}
 \end{tabular}
-\lstMakeShortInline@
 \end{cquote}
 However, the loop prints the values from 0 to 13 because there is no actual enumeration.
@@ -513 +500 @@
 \begin{figure}
 \centering
-\lstDeleteShortInline@
 \begin{tabular}{@{}l|l@{}}
 \multicolumn{1}{@{}c|}{non-object oriented} & \multicolumn{1}{c@{}}{object oriented} \\
@@ -553 +539 @@
 \end{Java}
 \end{tabular}
-\lstMakeShortInline@
 \caption{Java: Free Routine Versus Class Enumeration}
 \label{f:JavaFreeVersusClass}
@@ -607 +592 @@
 \section{Rust}
 \lstnewenvironment{rust}[1][]{\lstset{language=Rust,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+% https://doc.rust-lang.org/reference/items/enumerations.html
 
 Rust provides a scoped enumeration based on variant types.
@@ -1010 +996 @@
 
 
-\section{Python}
+\section{Python 3.13}
 \lstnewenvironment{python}[1][]{\lstset{language=Python,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
-
-A Python enumeration is a set of symbolic names bound to \emph{unique} values.
-They are similar to global variables, but offer a more useful @repr()@, grouping, type-safety, and additional features.
-Enumerations inherits from the @Enum@ class, \eg:
-\begin{python}
-class Weekday(@Enum@): Mon = 1; Tue = 2; Wed = 3; Thu = 4; Fri = 5; Sat = 6; Sun = 7
-class RGB(@Enum@): Red = 1; Green = 2; Blue = 3
-\end{python}
-
-Depending on the nature of the enum a member's value may or may not be important, but either way that value can be used to get the corresponding member:
-\begin{python}
-print( repr( Weekday( 3 ) ) )
-<Weekday.Wed: 3>
-\end{python}
-As you can see, the @repr()@ of a member shows the enum name, the member name, and the value.
-The @str()@ of a member shows only the enum name and member name:
-\begin{python}
-print( str( Weekday.Thu ), Weekday.Thu )
-Weekday.Thu Weekday.Thu
-\end{python}
-The type of an enumeration member is the enum it belongs to:
-\begin{python}
-print( type( Weekday.Thu ) )
-<enum 'Weekday'>
-print( isinstance(Weekday.Fri, Weekday) )
-True
-\end{python}
-Enum members have an attribute that contains just their name:
-\begin{python}
-print(Weekday.TUESDAY.name)
-TUESDAY
-\end{python}
-Likewise, they have an attribute for their value:
-\begin{python}
-Weekday.WEDNESDAY.value
-3
-\end{python}
-
-Unlike many languages that treat enumerations solely as name/value pairs, Python @Enum@s can have behavior added.
-For example, @datetime.date@ has two methods for returning the weekday: @weekday()@ and @isoweekday()@.
-The difference is that one of them counts from 0-6 and the other from 1-7.
-Rather than keep track of that ourselves we can add a method to the @Weekday@ enum to extract the day from the date instance and return the matching enum member:
-\begin{python}
-class Weekday(Enum): Mon = 1; Tue = 2; Wed = 3; Thu = 10; Fri = 15; Sat = 16; Sun = 17
-$@$classmethod
-def from_date(cls, date):
-        return cls(date.isoweekday())
-\end{python}
-Now we can find out what today is! Observe:
-\begin{python}
->>> from datetime import date
->>> Weekday.from_date(date.today())     
-<Weekday.TUESDAY: 2>
-\end{python}
-Of course, if you're reading this on some other day, you'll see that day instead.
-
-This Weekday enum is great if our variable only needs one day, but what if we need several? Maybe we're writing a function to plot chores during a week, and don't want to use a @list@ -- we could use a different type of @Enum@:
-\begin{python}
-from enum import Flag
-class WeekdayF(@Flag@): Mon = @1@; Tue = @2@; Wed = @4@; Thu = @8@; Fri = @16@; Sat = @32@; Sun = @64@
-\end{python}
-We've changed two things: we're inherited from @Flag@, and the values are all powers of 2.
+% https://docs.python.org/3/howto/enum.html
+
+Python is a dynamically-typed reflexive programming language with multiple versions, and hence, it is possible to extend existing or build new language features within the language.
+As a result, discussing Python enumerations is a moving target, because if a features does not exist, if can often be created with varying levels of complexity.
+Nevertheless, an attempt has been made to discuss core enumeration features that come with Python 3.13.
+
+A Python enumeration type is a set of ordered scoped identifiers (enumerators) bound to \emph{unique} values.
+An enumeration is not a basic type;
+it is a @class@ inheriting from the @Enum@ class, where the enumerators must be explicitly initialized, \eg:
+\begin{python}
+class Week(@Enum@): Mon = 1; Tue = 2; Wed = 3; Thu = 4; Fri = 5; Sat = 6; Sun = 7
+\end{python}
+and/or explicitly auto initialized, \eg:
+\begin{python}
+class Week(Enum): Mon = 1; Tue = 2; Wed = 3; Thu = 10; Fri = @auto()@; Sat = 4; Sun = @auto()@
+\end{python}
+where @auto@ increments by 1 from the previous enumerator value.
+Object initialization and assignment are restricted to the enumerators of this type.
+An enumerator initialized with same value is an alias and invisible at the enumeration level, \ie the alias it substituted for its aliasee.
+\begin{python}
+class Week(Enum): Mon = 1; Tue = 2; Wed = 3; Thu = 10; Fri = @10@; Sat = @10@; Sun = @10@
+\end{python}
+Here, the enumeration has only 4 enumerators and 3 aliases.
+An alias is only visible by dropping down to the @class@ level and asking for class members.
+@Enum@ only supports equality comparison between enumerator values;
+the extended class @OrderedEnum@ adds relational operators @<@, @<=@, @>@, and @>=@.
+
+There are bidirectional enumeration pseudo-functions for label and value, but there is no concept of access using ordering (position).
+\begin{cquote}
+\setlength{\tabcolsep}{15pt}
+\begin{tabular}{@{}ll@{}}
+\begin{python}
+Week.Thu.value == 10;
+Week.Thu.name == 'Thu';
+\end{python}
+&
+\begin{python}
+Week( 10 ) == Thu
+Week['Thu'].value = 10
+\end{python}
+\end{tabular}
+\end{cquote}
+
+As an enumeration is a \lstinline[language=python]{class}, its own methods.
+\begin{python}
+class Week(Enum):
+        Mon = 1; Tue = 2; Wed = 3; Thu = 4; Fri = 5; Sat = 6; Sun = 7
+        $\\@$classmethod
+        def today(cls, date):
+                return cls(date.isoweekday())
+print( "today:", Week.today(date.today()))
+today: Week.Mon
+\end{python}
+The method @today@ retrieves the day of the week and uses it as an index to print out the corresponding label of @Week@.
 
 @Flag@ allows combining several members into a single variable:
 \begin{python}
-print( repr(WeekdayF.Sat | WeekdayF.Sun) )
-<WeekdayF.Sun|Sat: 96>
+print( repr(WeekF.Sat | WeekF.Sun) )
+<WeekF.Sun|Sat: 96>
 \end{python}
 You can even iterate over a @Flag@ variable:
@@ -1084 +1062 @@
 for day in weekend:
         print(day)
-Weekday.SATURDAY
-Weekday.SUNDAY
+WeekF.Sat
+WeekF.Sun
 \end{python}
 Okay, let's get some chores set up:
 \begin{python}
 >>> chores_for_ethan = {
-...    'feed the cat': Weekday.MONDAY | Weekday.WEDNESDAY | Weekday.FRIDAY,
-...    'do the dishes': Weekday.TUESDAY | Weekday.THURSDAY,
-...    'answer SO questions': Weekday.SATURDAY,
+...    'feed the cat': Week.MONDAY | Week.WEDNESDAY | Week.FRIDAY,
+...    'do the dishes': Week.TUESDAY | Week.THURSDAY,
+...    'answer SO questions': Week.SATURDAY,
 ...    }
 \end{python}
@@ -1101 +1079 @@
 ...        if day in days:
 ...            print(chore)
->>> show_chores(chores_for_ethan, Weekday.SATURDAY)
+>>> show_chores(chores_for_ethan, Week.SATURDAY)
 answer SO questions
 \end{python}
-In cases where the actual values of the members do not matter, you can save yourself some work and use @auto()@ for the values:
-\begin{python}
->>> from enum import auto
->>> class Weekday(Flag):
-...    MONDAY = auto()
-...    TUESDAY = auto()
-...    WEDNESDAY = auto()
-...    THURSDAY = auto()
-...    FRIDAY = auto()
-...    SATURDAY = auto()
-...    SUNDAY = auto()
-...    WEEKEND = SATURDAY | SUNDAY
+Auto incrmenet for @Flag@ is by powers of 2.
+\begin{python}
+class WeekF(Flag): Mon = auto(); Tue = auto(); Wed = auto(); Thu = auto(); Fri = auto();  \
+                                                        Sat = auto(); Sun = auto(); Weekend = Sat | Sun
+for d in WeekF:
+        print( f"{d.name}: {d.value}", end=" ")
+Mon: 1 Tue: 2 Wed: 4 Thu: 8 Fri: 16 Sat: 32 Sun: 64 WeekA.Weekend
 \end{python}
 
@@ -1123 +1096 @@
 @Enum@ allows such access:
 \begin{python}
->>> Color(1)
-<Color.RED: 1>
->>> Color(3)
-<Color.BLUE: 3>
+print(RGB(1), RGB(3), )
+RGB.RED RGB.GREEN
 \end{python}
 If you want to access enum members by name, use item access:
 \begin{python}
-Color['RED']
-<Color.RED: 1>
-
-Color['GREEN']
-<Color.GREEN: 2>
+print( RGBa['RED'], RGBa['GREEN'] )
+RGB.RED RGB.GREEN
 \end{python}
 If you have an enum member and need its name or value:
 \begin{python}
->>> member = Color.RED
->>> member.name
-'RED'
->>> member.value
-1
-\end{python}
-
-\subsection{Duplicating enum members and values}
-
-An enum member can have other names associated with it.
-Given two entries @A@ and @B@ with the same value (and @A@ defined first), @B@ is an alias for the member @A@.
-By-value lookup of the value of @A@ will return the member @A@.
-By-name lookup of @A@ will return the member @A@.
-By-name lookup of @B@ will also return the member @A@:
-\begin{python}
-class Shape(Enum): SQUARE = 2; DIAMOND = 1; CIRCLE = 3; ALIAS_FOR_SQUARE = 2
->>> Shape.SQUARE
-<Shape.SQUARE: 2>
->>> Shape.ALIAS_FOR_SQUARE
-<Shape.SQUARE: 2>
->>> Shape(2)
-<Shape.SQUARE: 2>
-\end{python}
-
-Note: Attempting to create a member with the same name as an already defined attribute (another member, a method, etc.) or attempting to create an attribute with the same name as a member is not allowed.
+member = RGBa.RED
+print( f"{member.name} {member.value}" )
+RED 1
+\end{python}
+
 
 \subsection{Ensuring unique enumeration values}
@@ -1207 +1155 @@
 >>> list(Shape)
 [<Shape.SQUARE: 2>, <Shape.DIAMOND: 1>, <Shape.CIRCLE: 3>]
->>> list(Weekday)
-[<Weekday.MONDAY: 1>, <Weekday.TUESDAY: 2>, <Weekday.WEDNESDAY: 4>, <Weekday.THURSDAY: 8>,
-<Weekday.FRIDAY: 16>, <Weekday.SATURDAY: 32>, <Weekday.SUNDAY: 64>]
-\end{python}
-Note that the aliases @Shape.ALIAS_FOR_SQUARE@ and @Weekday.WEEKEND@ aren't shown.
+>>> list(Week)
+[<Week.MONDAY: 1>, <Week.TUESDAY: 2>, <Week.WEDNESDAY: 4>, <Week.THURSDAY: 8>,
+<Week.FRIDAY: 16>, <Week.SATURDAY: 32>, <Week.SUNDAY: 64>]
+\end{python}
+Note that the aliases @Shape.ALIAS_FOR_SQUARE@ and @Week.WEEKEND@ aren't shown.
 
 The special attribute @__members__@ is a read-only ordered mapping of names to members.
@@ -2218 +2166 @@
 
 OCaml provides a variant (union) type, where multiple heterogeneously-typed objects share the same storage.
-The simplest form of the variant type is a list of nullary datatype constructors, which is like an unscoped, pure enumeration.
-
-(I think the value of a ocaml variants are types not object, so I am not sure about this line)
+The simplest form of the variant type is a list of nullary datatype constructors, which is like an unscoped, opaque enumeration.
+
 OCaml provides a variant (union) type, which is an aggregation of heterogeneous types.
-A basic variant is a list of nullary datatype constructors, which is like an unscoped, pure enumeration. 
+A basic variant is a list of nullary datatype constructors, which is like an unscoped, opaque enumeration.
 \begin{ocaml}
 type weekday = Mon | Tue | Wed | Thu | Fri | Sat | Sun
@@ -2246 +2193 @@
 type colour = Red | Green of @string@ | Blue of @int * float@
 \end{ocaml}
-A variant with parameter is stored in a memory block, prefixed by an int tag and has its parameters stores as words in the block. 
+A variant with parameter is stored in a memory block, prefixed by an int tag and has its parameters stores as words in the block.
 @colour@ is a summation of a nullary type, a unary product type of @string@, and a cross product of @int@ and @float@.
 (Mathematically, a @Blue@ value is a Cartesian product of the types @int@ type and @float@.)
@@ -2259 +2206 @@
 @Red, abc, 1 1.5@
 \end{ocaml}
-
 
 A variant type can have a recursive definition.
@@ -2280 +2226 @@
 
 In summary, an OCaml variant is a singleton value rather than a set of possibly ordered values, and hence, has no notion of enumerabilty.
-Therefore it is not an enumeration, except for the simple pure (nullary) case.
+Therefore it is not an enumeration, except for the simple opaque (nullary) case.
 
 \begin{comment}
@@ -2466 +2412 @@
 With valediction,
   - Gregor Richards
+
+
+Date: Tue, 16 Apr 2024 11:04:51 -0400
+Subject: Re: C unnamed enumeration
+To: "Peter A. Buhr" <pabuhr@uwaterloo.ca>
+CC: <ajbeach@uwaterloo.ca>, <j82liang@uwaterloo.ca>, <mlbrooks@uwaterloo.ca>,
+        <f37yu@uwaterloo.ca>
+From: Gregor Richards <gregor.richards@uwaterloo.ca>
+
+On 4/16/24 09:55, Peter A. Buhr wrote:
+> So what is a variant? Is it a set of tag names, which might be a union or is it
+> a union, which might have tag names?
+
+Your tagless variant bears no resemblance to variants in any functional
+programming language. A variant is a tag AND a union. You might not need to put
+anything in the union, in which case it's a pointless union, but the named tag
+is absolutely mandatory. That's the thing that varies.
+
+I was unaware of std::variant. As far as functional languages are concerned,
+std::variant IS NOT A VARIANT. Perhaps it would be best to use the term ADT for
+the functional language concept, because that term has no other meanings.
+
+An ADT cannot not have a named tag. That's meaningless. The tag is the data
+constructor, which is the thing you actually define when you define an ADT. It
+is strictly the union that's optional.
+
+With valediction,
+  - Gregor Richards
 \end{comment}
 
@@ -2487 +2461 @@
 \hline
 \hline
-pure                    &               &               &               &               &               &               &               &               &               &               &               &               & \CM   \\
+opaque                  &               &               &               &               &               &               &               &               &               &               &               &               & \CM   \\
 \hline
 typed                   &               &               &               &               &               &               &               &               &               &               & @int@ & integral      & @T@   \\