Changeset 7042c60 for doc

doc/LaTeXmacros/common.sty

-              rcf191ac
+              r7042c60
 %% Created On       : Sat Apr  9 10:06:17 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Sun Feb 25 23:30:09 2024
 %% Update Count     : 645
+%% Last Modified On : Thu Apr 18 09:14:02 2024
+%% Update Count     : 657
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \renewcommand\subparagraph{\@startsection{subparagraph}{4}{\z@}{-1.5ex \@plus -1ex \@minus -.2ex}{-1em}{\normalfont\normalsize\bfseries\itshape}}
-% index macros
 \newcommand{\italic}[1]{\emph{\hyperpage{#1}}}
 \newcommand{\Definition}[1]{\textbf{\hyperpage{#1}}}
+\newcommand{\see}[1]{(see #1)}
+\newcommand{\see}{\protect\@ifstar\@ssee\@see}
+\newcommand{\@ssee}[1]{(See #1)}
+\newcommand{\@see}[1]{(see #1)}
+% index macros
 % Define some commands that produce formatted index entries suitable for cross-references.
 …
 \newcommand{\newtermFontInline}{\emph}
 \newcommand{\newterm}{\protect\@ifstar\@snewterm\@newterm}
+\newcommand{\@snewterm}[2][\@empty]{{\newtermFontInline{#2}}\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
 \newcommand{\@newterm}[2][\@empty]{\lowercase{\def\temp{#2}}{\newtermFontInline{#2}}\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
-\newcommand{\@snewterm}[2][\@empty]{{\newtermFontInline{#2}}\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
 % \snake{<identifier>}
 …
 \newenvironment{cquote}{%
         \list{}{\lstset{resetmargins=true,aboveskip=0pt,belowskip=0pt}\topsep=4pt\parsep=0pt\leftmargin=\parindentlnth\rightmargin\leftmargin}%
+        \list{}{\topsep=\lst@aboveskip\parskip=0pt\partopsep=0pt\itemsep=0pt\parsep=0pt\listparindent=0pt\leftmargin=\parindentlnth\rightmargin=0pt}%
         \item\relax
+        \lstset{resetmargins=true}
 }{%
         \endlist
 …
 \fi%
+\usepackage{tabularx}                                   % if @ is used for lstMakeShortInline, allows @{}
 % Local Variables: %
 % tab-width: 4 %

doc/LaTeXmacros/common.tex

-              rcf191ac
+              r7042c60
 %% Created On       : Sat Apr  9 10:06:17 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Mon Feb 26 08:06:05 2024
 %% Update Count     : 615
+%% Last Modified On : Thu Apr 18 09:15:38 2024
+%% Update Count     : 664
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \renewcommand\subparagraph{\@startsection{subparagraph}{4}{\z@}{-1.5ex \@plus -1ex \@minus -.2ex}{-1em}{\normalfont\normalsize\bfseries\itshape}}
-% index macros
 \newcommand{\italic}[1]{\emph{\hyperpage{#1}}}
 \newcommand{\Definition}[1]{\textbf{\hyperpage{#1}}}
+\newcommand{\see}[1]{(see #1)}
+\newcommand{\see}{\protect\@ifstar\@ssee\@see}
+\newcommand{\@ssee}[1]{(See #1)}
+\newcommand{\@see}[1]{(see #1)}
+% index macros
 % Define some commands that produce formatted index entries suitable for cross-references.
 …
 \newcommand{\newtermFontInline}{\emph}
 \newcommand{\newterm}{\protect\@ifstar\@snewterm\@newterm}
+\newcommand{\@snewterm}[2][\@empty]{{\newtermFontInline{#2}}\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
 \newcommand{\@newterm}[2][\@empty]{\lowercase{\def\temp{#2}}{\newtermFontInline{#2}}\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
-\newcommand{\@snewterm}[2][\@empty]{{\newtermFontInline{#2}}\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
 % \snake{<identifier>}
 …
 \newcommand{\VS}{\abbrevFont{vs}}
 \newcommand{\vs}{\VS\CheckPeriod}
-\makeatother
 \newenvironment{cquote}{%
         \list{}{\lstset{resetmargins=true,aboveskip=0pt,belowskip=0pt}\topsep=4pt\parsep=0pt\leftmargin=\parindentlnth\rightmargin\leftmargin}%
+        \list{}{\topsep=\lst@aboveskip\parskip=0pt\partopsep=0pt\itemsep=0pt\parsep=0pt\listparindent=0pt\leftmargin=\parindentlnth\rightmargin=0pt}%
         \item\relax
+        \lstset{resetmargins=true}
 }{%
         \endlist
 }% cquote
+\makeatother
 \newenvironment{rationale}{%
 …
 \fi%
+\usepackage{tabularx}                                   % if @ is used for lstMakeShortInline, allows @{}
 % Local Variables: %
 % tab-width: 4 %

doc/LaTeXmacros/lstlang.sty

-              rcf191ac
+              r7042c60
 %% Created On       : Sat May 13 16:34:42 2017
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Tue Mar 12 17:29:58 2024
 %% Update Count     : 42
+%% Last Modified On : Mon Apr 15 11:28:44 2024
+%% Update Count     : 43
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
                 alignas, _Alignas, alignof, _Alignof, __alignof, __alignof__, and, asm, __asm, __asm__, _Atomic, __attribute, __attribute__,
                 __auto_type, basetypeof, _Bool, catch, catchResume, choose, coerce, corun, cofor, _Complex, __complex, __complex__,
                 __const, __const__, continue, _Decimal32, _Decimal64, _Decimal128, disable, dtype, enable, exception, __extension__,
+                __const, __const__, continue, coroutine, _Decimal32, _Decimal64, _Decimal128, disable, dtype, enable, exception, __extension__,
                 fallthrough, fallthru, finally, fixup, __float80, float80, __float128, float128, _Float16, _Float32, _Float32x, _Float64,
                 _Float64x, _Float128, _Float128x, forall, fortran, ftype, generator, _Generic, _Imaginary, __imag, __imag__, inline,

doc/bibliography/pl.bib

-              rcf191ac
+              r7042c60
     year        = 1963,
     pages       = {1-17},
+}
+@misc{AlgolW,
+    keywords    = {AlgolW},
+    contributer = {pabuhr@plg},
+    author      = {Henry Bauer and Sheldon Becker and Susan L. Graham and Edwin Satterthwaite and Richard L. Sites},
+    title       = {{Algol W} Language Description},
+    month       = jun,
+    year        = 1972,
+    howpublished= {\url{https://www.algol60.org/docsW/algolw.pdf}},
+}

doc/theses/jiada_liang_MMath/CFAenum.tex

rcf191ac	r7042c60
137	137	\section{Pure Enumerators}
138	138
139		An empty enumerator type, @enum()@, implies the enumerators are ~~pur~~e symbols without values but set properties;
	139	An empty enumerator type, @enum()@, implies the enumerators are opaque symbols without values but set properties;
140	140	hence, there is no default conversion to @int@.
141	141

doc/theses/jiada_liang_MMath/Makefile

-              rcf191ac
+              r7042c60
 BibSRC = ${wildcard *.bib}
 TeXLIB = .:${LaTMac}:${Build}:
 BibLIB = .:${BibRep}:
+TeXLIB = .:${LaTMac}:${Build}:                  # common latex macros
+BibLIB = .:${BibRep}:                           # common citation repository
 MAKEFLAGS = --no-print-directory # --silent

doc/theses/jiada_liang_MMath/background.tex

-              rcf191ac
+              r7042c60
 \chapter{Background}
-\lstnewenvironment{clang}[1][]{\lstset{language=[ANSI]C,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
 \CFA is a backwards-compatible extension of the C programming language.
 …
 \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

-              rcf191ac
+              r7042c60
 \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.
+In theory, there are an infinite set of primary constant names per type.
+\Newterm{Secondary naming} is a common practice in mathematics, engineering and computer science, \eg $\pi$, $\tau$ (2$\pi$), $\phi$ (golden ratio), MB (megabyte, 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 purpose is for readability and to eliminate duplication of the primary constant throughout a program.
+For example, a meaningful secondary name replaces a primary name throughout a program;
+thereafter, changing the binding of the secondary to primary name automatically distributes the rebinding, preventing errors.
+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.}.
 Secondary names can form an (ordered) set, \eg days of the week, months of a year, floors of a building (basement, ground, 1st), colours in a rainbow, \etc.
+Secondary names can form an (ordered) set, \eg days of a week, months of a year, floors of a building (basement, ground, 1st), colours in a rainbow, \etc.
 Many programming languages capture these groupings through a mechanism called an \Newterm{enumeration}.
 \begin{quote}
 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.
 …
 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
+Ordering allows iterating among the enumeration set using relational operators and advancement, \eg:
 \begin{cfa}
 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 representation 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
+\begin{sloppypar}
+It provides a finite set of secondary names, which become its primary constants.
+This differentiates an enumeration from general types with an infinite set
+of primary constants.
+\end{sloppypar}
+\item
+The secondary names are constants, which follows transitively from their binding (aliasing) to primary names, which are constants.
+\item
+Defines a type for generating instants (variables).
+\item
+For safety, an enumeration instance should be 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.
+As well, an enumerated type has three fundamental properties, \Newterm{label}, \Newterm{order}, and \Newterm{value}.
+\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} for the name derivation}.
+As well, an enumerated type can have three fundamental properties, \Newterm{label}, \Newterm{order}, and \Newterm{value}.
 \begin{cquote}
 \sf\setlength{\tabcolsep}{3pt}
 \begin{tabular}{rcccccccr}
 \it\color{red}enumeration       & \multicolumn{8}{c}{\it\color{red}enumerators} \\
 $\downarrow$\hspace*{25pt}      & \multicolumn{8}{c}{$\downarrow$}                              \\
 @enum@ Week \{                          & Mon,  & Tue,  & Wed,  & Thu,  & Fri,  & Sat,  & Sun = 42      & \};   \\
+$\downarrow$\hspace*{15pt}      & \multicolumn{8}{c}{$\downarrow$}                              \\
+@enum@ Week \{                          & Mon,  & Tue,  & Wed,  & Thu,  & Fri,  & Sat,  & Sun {\color{red}= 42} & \};   \\
 \it\color{red}label                     & Mon   & Tue   & Wed   & Thu   & Fri   & Sat   & Sun           &               \\
 \it\color{red}order                     & 0             & 1             & 2             & 3             & 4             & 5             & 6                     &               \\
 \it\color{red}value                     & 0             & 1             & 2             & 3             & 4             & 5             & 42            &
+\it\color{red}value                     & 0             & 1             & 2             & 3             & 4             & 5             & {\color{red}42}               &
 \end{tabular}
 \end{cquote}
 …
 \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.
+Many programming languages provide an enumeration-like mechanism, which may or may not cover the previous five fundamental enumeration aspects.
+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 featuring is being used.
+This section discusses some language features that are sometimes called an enumeration but do not provide all enumeration aspects.
+\subsection{Aliasing}
+Some languages provide simple secondary aliasing (renaming), \eg:
+\begin{cfa}
+const Size = 20, Pi = 3.14159, Name = "Jane";
+\end{cfa}
+The secondary name is logically replaced in the program text by its corresponding primary name.
+Therefore, it is possible to compare the secondary names, \eg @Size < Pi@, only because the primary constants allow it, whereas \eg @Pi < Name@ might be disallowed depending on the language.
+Aliasing is not macro substitution, \eg @#define Size 20@, where a name is replaced by its value \emph{before} compilation, so the name is invisible to the programming language.
+With aliasing, each secondary name is part of the language, and hence, participates fully, such as name overloading in the type system.
+Aliasing is not an immutable variable, \eg:
+\begin{cfa}
+extern @const@ int Size = 20;
+extern void foo( @const@ int @&@ size );
+foo( Size ); // take the address of (reference) Size
+\end{cfa}
+Taking the address of an immutable variable makes it an \Newterm{lvalue}, which implies it has storage.
+With separate compilation, it is necessary to choose one translation unit to perform the initialization.
+If aliasing does require storage, its address and initialization are opaque (compiler only), similar to \CC rvalue reference @&&@.
+Aliasing does provide readability and automatic resubstitution.
+It also provides simple enumeration properties, 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}
+@variant@ Variant {
+        @int tag;@  // optional/implicit: 0 => int, 1 => double, 2 => S
+        @union {@ // implicit
+                case int i;
+                case double d;
+                case struct S { int i, j; } s;
+        @};@
+};
+\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:
+\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 */ }
+}
+\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
+        ...
+        @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}
+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 these reasons, aliasing is sometimes called an enumeration.
+However, there is no type to create a type-checked instance or iterator cursor, so there is no ability for enumerating.
+Hence, there are multiple enumeration aspects not provided by aliasing, justifying a separate enumeration type in a programming language.
+\subsection{Algebraic Data Type}
+An algebraic data type (ADT)\footnote{ADT is overloaded with abstract data type.} is another language feature often linked with enumeration, where an ADT conjoins an arbitrary type, possibly a \lstinline[language=C++]{class} or @union@, and a named constructor.
+For example, in Haskell:
+\begin{haskell}
+data S = S { i::Int, d::Double }                $\C{// structure}$
+data @Foo@ = A Int | B Double | C S             $\C{// ADT, composed of three types}$
+foo = A 3;                                                              $\C{// type Foo is inferred}$
+bar = B 3.5
+baz = C S{ i = 7, d = 7.5 }
+\end{haskell}
+the ADT has three variants (constructors), @A@, @B@, @C@ with associated types @Int@, @Double@, and @S@.
+The constructors create an initialized value of the specific type that is bound to the immutable variables @foo@, @bar@, and @baz@.
+Hence, the ADT @Foo@ is like a union containing values of the associated types, and a constructor name is used to access the value using dynamic pattern-matching.
+\begin{cquote}
+\setlength{\tabcolsep}{15pt}
+\begin{tabular}{@{}ll@{}}
+\begin{haskell}
+prtfoo val = -- function
+    -- pattern match on constructor
+    case val of
+      @A@ a -> print a
+      @B@ b -> print b
+      @C@ (S i d) -> do
+          print i
+          print d
+\end{haskell}
+&
+\begin{haskell}
+main = do
+    prtfoo foo
+    prtfoo bar
+    prtfoo baz
+.5
+.5
+\end{haskell}
+\end{tabular}
+\end{cquote}
+For safety, most languages require all assocaited types to be listed or a default case with no field accesses.
+A less frequent case is multiple constructors with the same type.
+\begin{haskell}
+data Bar = X Int | Y Int | Z Int;
+foo = X 3;
+bar = Y 3;
+baz = Z 5;
+\end{haskell}
+Here, the constructor name gives different meaning to the values in the common \lstinline[language=Haskell]{Int} type, \eg the value @3@ has different interpretations depending on the constructor name in the pattern matching.
+Note, the term \Newterm{variant} is often associated with ADTs.
+However, there are multiple languages with a @variant@ type that is not an ADT \see{Algol68~\cite{Algol68} or \CC \lstinline{variant}}.
+In these languages, the variant is often a union using RTTI tags, which cannot be used to simulate an enumeration.
+Hence, in this work the term variant is not a synonym for ADT.
+% https://downloads.haskell.org/ghc/latest/docs/libraries/base-4.19.1.0-179c/GHC-Enum.html
+% https://hackage.haskell.org/package/base-4.19.1.0/docs/GHC-Enum.html
+The association between ADT and enumeration occurs if all the constructors have a unit (empty) type, \eg @struct unit {}@.
+Note, the unit type is not the same as \lstinline{void}, \eg:
+\begin{cfa}
+void foo( void );
+struct unit {} u;  // empty type
+unit bar( unit );
+foo( foo() );        // void argument does not match with void parameter
+bar( bar( u ) );   // unit argument does match with unit parameter
+\end{cfa}
+For example, in the Haskell ADT:
+\begin{haskell}
+data Week = Mon | Tue | Wed | Thu | Fri | Sat | Sun deriving(Enum, Eq, Show)
+\end{haskell}
+the default type for each constructor is the unit type, and deriving from @Enum@ enforces no other type, @Eq@ allows equality comparison, and @Show@ is for printing.
+The nullary constructors for the unit types are numbered left-to-right from $0$ to @maxBound@$- 1$, and provides enumerating operations @succ@, @pred@, @enumFrom@ @enumFromTo@.
+\VRef[Figure]{f:HaskellEnumeration} shows enumeration comparison and iterating (enumerating).
+\begin{figure}
+\begin{cquote}
+\setlength{\tabcolsep}{15pt}
+\begin{tabular}{@{}ll@{}}
+\begin{haskell}
+day = Tue
+main = do
+    if day == Tue then
+        print day
+    else
+        putStr "not Tue"
+    print (enumFrom Mon)            -- week
+    print (enumFromTo Mon Fri)   -- weekday
+    print (enumFromTo Sat Sun)  -- weekend
+\end{haskell}
+&
+\begin{haskell}
+Tue
+[Mon,Tue,Wed,Thu,Fri,Sat,Sun]
+[Mon,Tue,Wed,Thu,Fri]
+[Sat,Sun]
+\end{haskell}
+\end{tabular}
+\end{cquote}
+\caption{Haskell Enumeration}
+\label{f:HaskellEnumeration}
+\end{figure}
+The key observation is the dichotomy between an ADT and enumeration: the ADT uses the associated type resulting in a union-like data structure, and the enumeration does not use the associated type, and hence, is not a union.
+While the enumeration is constructed using the ADT mechanism, it is so restricted it is not really an ADT.
+Furthermore, a general ADT cannot be an enumeration because the constructors generate different values making enumerating meaningless.
+While functional programming languages regularly repurpose the ADT type into an enumeration type, this process seems contrived and confusing.
+Hence, there is only a weak equivalence between an enumeration and ADT, justifying a separate enumeration type in a programming language.
 \section{Contributions}
 The goal of this work is to to extend the simple and unsafe enumeration type in the C programming-language into a sophisticated and safe type in the \CFA programming-language, while maintain backwards compatibility with C.
+The goal of this work is to to extend 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.
 On the surface, enumerations seem like a simple type.
 However, when extended with advanced features, enumerations become complex for both the type system and the runtime implementation.
+The contribution of this work are:
 \begin{enumerate}
 \item
 …
 typing
 \item
 subset
+subseting
 \item
 inheritance

doc/theses/jiada_liang_MMath/relatedwork.tex

-              rcf191ac
+              r7042c60
 \section{Pascal}
 \label{s:Pascal}
-\lstnewenvironment{pascal}[1][]{\lstset{language=pascal,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
 Classic Pascal has the \lstinline[language=pascal]{const} declaration binding a name to a constant literal/expression.
 …
 \section{Ada}
+\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)}.
 …
 \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;
 …
 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@{}}
 …
 \end{ada}
 \end{tabular}
-\lstMakeShortInline@
 \end{cquote}
 These attributes are important for IO.
 …
 \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 := '+';
 …
 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@{}}
 …
 \end{ada}
 \end{tabular}
-\lstMakeShortInline@
 \end{cquote}
 …
 \section{\CC}
 \label{s:C++RelatedWork}
-\lstnewenvironment{c++}[1][]{\lstset{language=[GNU]C++,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
 \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;
 …
                                 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++}
 …
 \section{C\raisebox{-0.7ex}{\LARGE$^\sharp$}\xspace} % latex bug: cannot use \relsize{2} so use \LARGE
 \label{s:Csharp}
-\lstnewenvironment{csharp}[1][]{\lstset{language=[Sharp]C,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
 % https://www.tutorialsteacher.com/codeeditor?cid=cs-mk8Ojx
 …
 \begin{figure}
 \centering
-\lstDeleteShortInline@
 \begin{tabular}{@{}l|l@{}}
 \multicolumn{1}{@{}c|}{non-object oriented} & \multicolumn{1}{c@{}}{object oriented} \\
 …
 \end{csharp}
 \end{tabular}
-\lstMakeShortInline@
 \caption{\Csharp: Free Routine Versus Class Enumeration}
 \label{CsharpFreeVersusClass}
 …
 \section{Golang}
-\lstnewenvironment{Go}[1][]{\lstset{language=Go,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
 Golang provides pseudo-enumeration similar to classic Pascal \lstinline[language=pascal]{const}, binding a name to a constant literal/expression.
 …
 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.
 …
 Basic switch and looping are possible.
 \begin{cquote}
-\lstDeleteShortInline@
 \setlength{\tabcolsep}{15pt}
 \begin{tabular}{@{}ll@{}}
 …
 \end{Go}
 \end{tabular}
-\lstMakeShortInline@
 \end{cquote}
 However, the loop prints the values from 0 to 13 because there is no actual enumeration.
 …
 \section{Java}
-\lstnewenvironment{Java}[1][]{\lstset{language=Java,morekeywords={enum,assert,strictfp},
-        escapechar=\$,moredelim=**[is][\color{red}]{!}{!},}\lstset{#1}}{}
 Every enumeration in Java is an enumeration class.
 …
 \begin{figure}
 \centering
-\lstDeleteShortInline@
 \begin{tabular}{@{}l|l@{}}
 \multicolumn{1}{@{}c|}{non-object oriented} & \multicolumn{1}{c@{}}{object oriented} \\
 …
 \end{Java}
 \end{tabular}
-\lstMakeShortInline@
 \caption{Java: Free Routine Versus Class Enumeration}
 \label{f:JavaFreeVersusClass}
 …
 \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.
 …
 \section{Swift}
-\lstnewenvironment{swift}[1][]{\lstset{language=Swift,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
 % https://www.programiz.com/swift/online-compiler
 …
+\section{Python}
+\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
+\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.
+\section{Python 3.13}
+% 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:
 …
 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}
 …
 ...        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}
 …
 @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
+\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}
 …
 >>> 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.
 …
 \section{OCaml}
-\lstnewenvironment{ocaml}[1][]{\lstset{language=OCaml,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
 % https://ocaml.org/docs/basic-data-types#enumerated-data-types
 …
 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
 …
 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@.)
 …
 @Red, abc, 1 1.5@
 \end{ocaml}
 A variant type can have a recursive definition.
 …
 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}
 …
 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}
 …
 \hline
 \hline
 pure                    &               &               &               &               &               &               &               &               &               &               &               &               & \CM   \\
+opaque                  &               &               &               &               &               &               &               &               &               &               &               &               & \CM   \\
 \hline
 typed                   &               &               &               &               &               &               &               &               &               &               & @int@ & integral      & @T@   \\

doc/theses/jiada_liang_MMath/uw-ethesis.bib

-              rcf191ac
+              r7042c60
 % For use with BibTeX
+Oxford English Dictionary, s.v. ``enumerate (v.), sense 3,'' September 2023, https://doi.org/10.1093/OED/1113960777.
+@misc{OEDenumerate,
+    keywords    = {enumerate},
+    key         = {enumerate},
+    title       = {enumerate (v.), sense 3},
+    author      = {Oxford English Dictionary},
+    howpublished= {\url{https://doi.org/10.1093/OED/1113960777}},
+    month       = sep,
+    year        = 2023,
+}

doc/theses/jiada_liang_MMath/uw-ethesis.tex

-              rcf191ac
+              r7042c60
 \CFAStyle                                               % CFA code-style
 \lstset{language=cfa,belowskip=-1pt} % set default language to CFA
+\lstnewenvironment{ada}[1][]{\lstset{language=[2005]Ada,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},literate={'}{\ttfamily'\!}1}\lstset{#1}}{}
+\lstnewenvironment{c++}[1][]{\lstset{language=[GNU]C++,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+\lstnewenvironment{pascal}[1][]{\lstset{language=pascal,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+\lstnewenvironment{csharp}[1][]{\lstset{language=[Sharp]C,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+\lstnewenvironment{clang}[1][]{\lstset{language=[ANSI]C,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+\lstnewenvironment{Go}[1][]{\lstset{language=Go,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+\lstnewenvironment{haskell}[1][]{\lstset{language=Haskell,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+\lstnewenvironment{Java}[1][]{\lstset{language=Java,morekeywords={enum,assert,strictfp},
+        escapechar=\$,moredelim=**[is][\color{red}]{!}{!},}\lstset{#1}}{}
+\lstnewenvironment{rust}[1][]{\lstset{language=Rust,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+\lstnewenvironment{swift}[1][]{\lstset{language=Swift,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+\lstnewenvironment{python}[1][]{\lstset{language=Python,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+\lstnewenvironment{ocaml}[1][]{\lstset{language=OCaml,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+\newsavebox{\myboxA}
+\newsavebox{\myboxB}
 \newcommand{\newtermFont}{\emph}

doc/uC++toCFA/Makefile

-              rcf191ac
+              r7042c60
         dvips ${Build}/$< -o $@
 ${BASE}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} \
                 ${Macros}/common.sty ${Macros}/lstlang.sty ${Macros}/indexstyle ../bibliography/pl.bib build/version | ${Build}
+${BASE}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${Macros}/common.tex ${Macros}/common.sty \
+                ${Macros}/lstlang.sty ${Macros}/indexstyle ../bibliography/pl.bib build/version | ${Build}
         # Conditionally create an empty *.ind (index) file for inclusion until makeindex is run.
         if [ ! -r ${basename $@}.ind ] ; then touch ${Build}/${basename $@}.ind ; fi

doc/uC++toCFA/uC++toCFA.tex

-              rcf191ac
+              r7042c60
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Thu Jan 11 14:46:14 2024
 %% Update Count     : 5942
+%% Last Modified On : Sat Apr 13 11:11:39 2024
+%% Update Count     : 5969
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \CFA uses parametric polymorphism and allows overloading of variables and routines:
 \begin{cfa}
 int i;  char i;  double i;              // overload name i
+int i;  char i;  double i;      $\C[2in]{// overload name i}$
 int i();  double i();  char i();
 i += 1;                 $\C[1.5in]{// int i}$
 i += 1.0;               $\C{// double i}$
 i += 'a';               $\C{// char i}$
 int j = i();    $\C{// int i()}$
 double j = i(); $\C{// double i();}$
 char j = i();   $\C{// char i()}\CRT$
+i += 1;                                         $\C{// int i}$
+i += 1.0;                                       $\C{// double i}$
+i += 'a';                                       $\C{// char i}$
+int j = i();                            $\C{// int i()}$
+double j = i();                         $\C{// double i();}$
+char j = i();                           $\C{// char i()}\CRT$
 \end{cfa}
 \CFA has rebindable references.
+\begin{cquote}
+\begin{tabular}{l|l}
+\multicolumn{2}{l}{\lstinline{  int x = 1, y = 2, * p1x = &x, * p1y = &y, ** p2i = &p1x,}} \\
+\multicolumn{2}{l}{\lstinline{\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ && r1x = x, & r1y = y, && r2i = r1x;}} \\
+\begin{cquote}
+\begin{tabular}{@{}l|l@{}}
+\multicolumn{2}{@{}l}{\lstinline{       int x = 1, y = 2, * p1x = &x, * p1y = &y, ** p2i = &p1x,}} \\
+\multicolumn{2}{@{}l}{\lstinline{\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ && r1x = x, & r1y = y, && r2i = r1x;}} \\
 \begin{uC++}
 **p2i = 3;
 …
 \CFA output streams automatically separate values and insert a newline at the end of the print.
+\begin{cquote}
+\begin{tabular}{l|l}
+\begin{cquote}
+\begin{tabular}{@{}l|l@{}}
 \begin{uC++}
 #include <@iostream@>
 …
 \begin{cquote}
 \begin{tabular}{l|l}
+\begin{tabular}{@{}l|l@{}}
 \begin{uC++}
 for ( @;;@ ) { ... }  /  while ( @true@ ) { ... }
 …
 Currently, \CFA uses macros @ExceptionDecl@ and @ExceptionInst@ to declare and instantiate an exception.
 \begin{cquote}
 \begin{tabular}{l|ll}
+\begin{tabular}{@{}l|ll@{}}
 \begin{uC++}
 …
 \begin{cquote}
 \begin{tabular}{l|ll}
+\begin{tabular}{@{}l|ll@{}}
 \begin{uC++}
 …
 \begin{cquote}
 \begin{tabular}{l|l}
+\begin{tabular}{@{}l|l@{}}
 \begin{uC++}
 struct S {
 …
 \begin{cquote}
 \begin{tabular}{l|l}
 \multicolumn{2}{l}{\lstinline{string s1, s2;}} \\
+\begin{tabular}{@{}l|l@{}}
+\multicolumn{2}{@{}l@{}}{\lstinline{string s1, s2;}} \\
 \begin{uC++}
 s1 = "hi";
 …
 \begin{cquote}
 \begin{tabular}{l|l}
+\begin{tabular}{@{}l|l@{}}
 \begin{uC++}
 struct S {
 …
 \begin{cquote}
 \begin{tabular}{l|l}
+\begin{tabular}{@{}l|l@{}}
 \begin{uC++}
 …
 \begin{cquote}
 \begin{tabular}{l|ll}
+\begin{tabular}{@{}l|ll@{}}
 \begin{uC++}
 …
 \begin{cquote}
 \begin{tabular}{l|ll}
+\begin{tabular}{@{}l|ll@{}}
 \begin{uC++}
 …
 \begin{cquote}
 \begin{tabular}{l|ll}
+\begin{tabular}{@{}l|ll@{}}
 \begin{uC++}
 …
 \begin{cquote}
 \begin{tabular}{l|ll}
+\begin{tabular}{@{}l|ll@{}}
 \begin{uC++}

doc/user/Makefile

-              rcf191ac
+              r7042c60
         dvips ${Build}/$< -o $@
 ${BASE}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} \
                 ${Macros}/common.sty ${Macros}/lstlang.sty ${Macros}/indexstyle ../bibliography/pl.bib build/version | ${Build}
+${BASE}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${Macros}/common.tex ${Macros}/common.sty \
+                ${Macros}/lstlang.sty ${Macros}/indexstyle ../bibliography/pl.bib build/version | ${Build}
         # Conditionally create an empty *.ind (index) file for inclusion until makeindex is run.
         if [ ! -r ${basename $@}.ind ] ; then touch ${Build}/${basename $@}.ind ; fi
 …
         makeindex -s ${Macros}/indexstyle ${Build}/${basename $@}.idx
         # Run again to finish citations
         ${LaTeX} ${basename $@}.tex
+#       ${LaTeX} ${basename $@}.tex
         # Run again to get index title into table of contents
 #       ${LaTeX} ${basename $@}.tex

doc/user/user.tex

-              rcf191ac
+              r7042c60
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Mon Feb 12 11:50:26 2024
 %% Update Count     : 6199
+%% Last Modified On : Tue Apr 23 14:13:10 2024
+%% Update Count     : 6623
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \lstset{language=CFA}                                                                   % CFA default lnaguage
 \lstnewenvironment{C++}[1][]                            % use C++ style
 {\lstset{language=C++,moredelim=**[is][\protect\color{red}]{®}{®},#1}}
+{\lstset{language=C++,escapechar=§,moredelim=**[is][\protect\color{red}]{®}{®},#1}}
 {}
 …
 \vspace*{\fill}
 \noindent
 \copyright\,2016, 2018, 2021 \CFA Project \\ \\
+\copyright\,2016, 2018, 2021, 2024 \CFA Project \\ \\
 \noindent
 This work is licensed under the Creative Commons Attribution 4.0 International License.
 …
 For example, it is possible to write a type-safe \CFA wrapper ©malloc© based on the C ©malloc©:
 \begin{cfa}
 forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
+forall( T & | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
 int * ip = malloc(); §\C{// select type and size from left-hand side}§
 double * dp = malloc();
 …
 while () { sout | "empty"; break; }
 do { sout | "empty"; break; } while ();
 for () { sout | "empty"; break; }                                                       §\C{sout | nl | nlOff;}§
 for ( 0 ) { sout | "A"; } sout | "zero";                                        §\C{sout | nl;}§
 for ( 1 ) { sout | "A"; }                                                                       §\C{sout | nl;}§
 for ( 10 ) { sout | "A"; }                                                                      §\C{sout | nl;}§
 for ( ~= 10 ) { sout | "A"; }                                                           §\C{sout | nl;}§
 for ( 1 ~= 10 ~ 2 ) { sout | "B"; }                                                     §\C{sout | nl;}§
 for ( 1 -~= 10 ~ 2 ) { sout | "C"; }                                            §\C{sout | nl;}§
 for ( 0.5 ~ 5.5 ) { sout | "D"; }                                                       §\C{sout | nl;}§
 for ( 0.5 -~ 5.5 ) { sout | "E"; }                                                      §\C{sout | nl;}§
 for ( i; 10 ) { sout | i; }                                                                     §\C{sout | nl;}§
 for ( i; ~= 10 ) { sout | i; }                                                          §\C{sout | nl;}§
 for ( i; 1 ~= 10 ~ 2 ) { sout | i; }                                            §\C{sout | nl;}§
 for ( i; 1 -~= 10 ~ 2 ) { sout | i; }                                           §\C{sout | nl;}§
 for ( i; 0.5 ~ 5.5 ) { sout | i; }                                                      §\C{sout | nl;}§
 for ( i; 0.5 -~ 5.5 ) { sout | i; }                                                     §\C{sout | nl;}§
 for ( ui; 2u ~= 10u ~ 2u ) { sout | ui; }                                       §\C{sout | nl;}§
 for ( ui; 2u -~= 10u ~ 2u ) { sout | ui; }                                      §\C{sout | nl | nl | nl;}§
+for () { sout | "empty"; break; }                               §\C[3in]{sout | nl | nlOff;}§
+for ( 0 ) { sout | "A"; } sout | "zero";                §\C{sout | nl;}§
+for ( 1 ) { sout | "A"; }                                               §\C{sout | nl;}§
+for ( 10 ) { sout | "A"; }                                              §\C{sout | nl;}§
+for ( ~= 10 ) { sout | "A"; }                                   §\C{sout | nl;}§
+for ( 1 ~= 10 ~ 2 ) { sout | "B"; }                             §\C{sout | nl;}§
+for ( 1 -~= 10 ~ 2 ) { sout | "C"; }                    §\C{sout | nl;}§
+for ( 0.5 ~ 5.5 ) { sout | "D"; }                               §\C{sout | nl;}§
+for ( 0.5 -~ 5.5 ) { sout | "E"; }                              §\C{sout | nl;}§
+for ( i; 10 ) { sout | i; }                                             §\C{sout | nl;}§
+for ( i; ~= 10 ) { sout | i; }                                  §\C{sout | nl;}§
+for ( i; 1 ~= 10 ~ 2 ) { sout | i; }                    §\C{sout | nl;}§
+for ( i; 1 -~= 10 ~ 2 ) { sout | i; }                   §\C{sout | nl;}§
+for ( i; 0.5 ~ 5.5 ) { sout | i; }                              §\C{sout | nl;}§
+for ( i; 0.5 -~ 5.5 ) { sout | i; }                             §\C{sout | nl;}§
+for ( ui; 2u ~= 10u ~ 2u ) { sout | ui; }               §\C{sout | nl;}§
+for ( ui; 2u -~= 10u ~ 2u ) { sout | ui; }              §\C{sout | nl | nl | nl;}§
 enum { N = 10 };
 for ( N ) { sout | "N"; }                                                                       §\C{sout | nl;}§
 for ( i; N ) { sout | i; }                                                                      §\C{sout | nl;}§
 for ( i; -~ N ) { sout | i; }                                                           §\C{sout | nl | nl | nl;}§
+for ( N ) { sout | "N"; }                                               §\C{sout | nl;}§
+for ( i; N ) { sout | i; }                                              §\C{sout | nl;}§
+for ( i; -~ N ) { sout | i; }                                   §\C{sout | nl | nl | nl;}§
 const int low = 3, high = 10, inc = 2;
 for ( i; low ~ high ~ inc + 1 ) { sout | i; }                           §\C{sout | nl;}§
 for ( i; 1 ~ @ ) { if ( i > 10 ) break; sout | i; }                     §\C{sout | nl;}§
 for ( i; @ -~ 10 ) { if ( i < 0 ) break; sout | i; }            §\C{sout | nl;}§
 for ( i; 2 ~ @ ~ 2 ) { if ( i > 10 ) break; sout | i; }         §\C{sout | nl;}§
+for ( i; low ~ high ~ inc + 1 ) { sout | i; }   §\C{sout | nl;}§
+for ( i; 1 ~ @ ) { if ( i > 10 ) break; sout | i; } §\C{sout | nl;}§
+for ( i; @ -~ 10 ) { if ( i < 0 ) break; sout | i; } §\C{sout | nl;}§
+for ( i; 2 ~ @ ~ 2 ) { if ( i > 10 ) break; sout | i; } §\C{sout | nl;}§
 for ( i; 2.1 ~ @ ~ @ ) { if ( i > 10.5 ) break; sout | i; i += 1.7; } §\C{sout | nl;}§
 for ( i; @ -~ 10 ~ 2 ) { if ( i < 0 ) break; sout | i; }        §\C{sout | nl;}§
 for ( i; 12.1 ~ @ ~ @ ) { if ( i < 2.5 ) break; sout | i; i -= 1.7; } §\C{sout | nl;}§
 for ( i; 5 : j; -5 ~ @ ) { sout | i | j; }                                      §\C{sout | nl;}§
 for ( i; 5 : j; @ -~ -5 ) { sout | i | j; }                                     §\C{sout | nl;}§
 for ( i; 5 : j; -5 ~ @ ~ 2 ) { sout | i | j; }                          §\C{sout | nl;}§
 for ( i; 5 : j; @ -~ -5 ~ 2 ) { sout | i | j; }                         §\C{sout | nl;}§
 for ( i; 5 : j; -5 ~ @ ) { sout | i | j; }                                      §\C{sout | nl;}§
 for ( i; 5 : j; @ -~ -5 ) { sout | i | j; }                                     §\C{sout | nl;}§
 for ( i; 5 : j; -5 ~ @ ~ 2 ) { sout | i | j; }                          §\C{sout | nl;}§
 for ( i; 5 : j; @ -~ -5 ~ 2 ) { sout | i | j; }                         §\C{sout | nl;}§
+for ( i; 5 : j; -5 ~ @ ) { sout | i | j; }              §\C{sout | nl;}§
+for ( i; 5 : j; @ -~ -5 ) { sout | i | j; }             §\C{sout | nl;}§
+for ( i; 5 : j; -5 ~ @ ~ 2 ) { sout | i | j; }  §\C{sout | nl;}§
+for ( i; 5 : j; @ -~ -5 ~ 2 ) { sout | i | j; } §\C{sout | nl;}§
+for ( i; 5 : j; -5 ~ @ ) { sout | i | j; }              §\C{sout | nl;}§
+for ( i; 5 : j; @ -~ -5 ) { sout | i | j; }             §\C{sout | nl;}§
+for ( i; 5 : j; -5 ~ @ ~ 2 ) { sout | i | j; }  §\C{sout | nl;}§
+for ( i; 5 : j; @ -~ -5 ~ 2 ) { sout | i | j; } §\C{sout | nl;}§
 for ( i; 5 : j; @ -~ -5 ~ 2 : k; 1.5 ~ @ ) { sout | i | j | k; } §\C{sout | nl;}§
 for ( i; 5 : j; @ -~ -5 ~ 2 : k; 1.5 ~ @ ) { sout | i | j | k; } §\C{sout | nl;}§
 for ( i; 5 : k; 1.5 ~ @ : j; @ -~ -5 ~ 2 ) { sout | i | j | k; } §\C{sout | nl;}§
+for ( i; 5 : k; 1.5 ~ @ : j; @ -~ -5 ~ 2 ) { sout | i | j | k; } §\C{sout | nl;}\CRT§
 \end{cfa}
+&
 …
 The string ``©int (*f(x))[ 5 ]©'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``©[ 5 ] int x©'' declares a \CFA style parameter ©x© of type array of 5 integers.
 Since the strings overlap starting with the open bracket, ©[©, there is an ambiguous interpretation for the string.
 As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity:
 \begin{cfa}
 …
 int f( int (* foo) ); §\C{// foo is redefined as a parameter name}§
 \end{cfa}
 The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
+The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to ©foo©.
 The redefinition of a type name in a parameter list is the only context in C where the character ©*© can appear to the left of a type name, and \CFA relies on all type qualifier characters appearing to the right of the type name.
 The inability to use \CFA declarations in these two contexts is probably a blessing because it precludes programmers from arbitrarily switching between declarations forms within a declaration contexts.
 …
 static [ int ] g ( int );
 \end{cfa}
+\subsection{Postfix Function}
+\label{s:PostfixFunction}
+\index{postfix function}
+\CFA provides an alternative call syntax where the argument appears before the function name.
+The syntax uses the backquote ©`© to separate the parameters/arguments and function name: ©?`© denotes a postfix-function name, \eg ©int ?`h( int s )© and ©`© denotes a postfix-function call, \eg ©0`h© meaning ©h( 0 )©.
+\begin{cquote}
+\begin{tabular}{@{}l|l|l|l@{}}
+postfix function & constant argument call & variable argument call & postfix function pointer \\
+\hline
+\begin{cfa}
+int ?`h( int s );
+int ?`h( double s );
+int ?`m( char c );
+int ?`m( const char * s );
+int ?`t( int a, int b, int c );
+\end{cfa}
+&
+\begin{cfa}
+`h;
+.5`h;
+'1'`m;
+"123" "456"`m;
+[1, 2, 3]`t;
+\end{cfa}
+&
+\begin{cfa}
+int i = 7;
+i`h;
+(i + 3)`h;
+(i + 3.5)`h;
+\end{cfa}
+&
+\begin{cfa}
+int (* ?`p)( int i );
+?`p = ?`h;
+`p;
+i`p;
+(i + 3)`p;
+\end{cfa}
+\end{tabular}
+\end{cquote}
+Note, to pass \emph{multiple} arguments to a postfix function requires a \Index{tuple}, \eg ©[1, 2, 3]`t©, which forms a single argument that is flattened into the multiple arguments \see{\VRef{s:Tuple}}.
+Similarly, if the argument is an expression, it must be parenthesized, \eg ©(i + 3)`h©, or only the last operand of the expression is the argument, \eg ©i + (3`h)©.
+\VRef[Figure]{f:UnitsComparison} shows a common usage for postfix functions: converting basic literals into user literals.
+\see*{\VRef{s:DynamicStorageManagement} for other uses for postfix functions.}
+The \CFA example (left) stores a mass in units of stones (1 stone = 14 lb or 6.35 kg) and provides an addition operator (imagine a full set of arithmetic operators).
+The three postfixing function names ©st©, ©lb©, and ©kg©, represent units stones, pounds, and kilograms, respectively.
+Each name has two forms that bidirectional convert: a value of a specified unit to stones, \eg ©w = 14`lb© $\Rightarrow$ ©w == 1© stone or a ©Weight© from stones back to specific units, \eg ©w`lb© (1 stone) to ©14©.
+All arithmetic operations manipulate stones and the postfix operations convert to the different units.
+A similar group of postfix functions provide user constants for converting time units into nanoseconds, which is the basic time unit, \eg ©ns©, ©us©, ©ms©, ©s©, ©m©, ©h©, ©d©, and ©w©, for nanosecond, microsecond, millisecond, second, minute, hour, day, and week, respectively.
+(Note, month is not a fixed period of time nor is year because of leap years.)
+\begin{figure}
+\centering
+\begin{tabular}{@{}l|l@{}}
+\multicolumn{1}{@{}c|}{\textbf{\CFA Postfix Routine}} & \multicolumn{1}{c@{}}{\textbf{\CC User Literals}} \\
+\hline
+\begin{cfa}
+struct Weight {
+        double stones;
+};
+Weight ?+?( Weight l, Weight r ) {
+        return l.stones + r.stones;
+}
+Weight ®?`st®( double w ) { return w; }
+double ®?`st®( Weight w ) { return w.stones; }
+Weight ®?`lb®( double w ) { return w / 14.0; }
+double ®?`lb®( Weight w ) { return w.stones * 14.0; }
+Weight ®?`kg®( double w ) { return w / 6.35; }
+double ®?`kg®( Weight w ) { return w.stones * 6.35; }
+int main() {
+        Weight w, heavy = { 20 }; // stones
+        w = 155®`lb®;
+        w = 0b_1111®`st®;
+        w = 0_233®`lb®;
+        w = 0x_9b®`kg®;
+        w = 5.5®`st® + 8®`kg® + 25.01®`lb® + heavy;
+}
+\end{cfa}
+&
+\begin{C++}
+struct Weight {
+        double stones;
+        Weight() {}
+        Weight( double w ) { stones = w; }
+};
+Weight operator+( Weight l, Weight r ) {
+        return l.stones + r.stones;
+}
+Weight operator®""_st®( long double w ) { return w; }
+Weight operator®""_lb®( long double w ) { return w / 14.0; }
+Weight operator®""_kg®( long double w ) { return w / 6.35; }
+Weight operator®""_st®( unsigned long long int w ) { return w; }
+Weight operator®""_lb®( unsigned long long int w ) { return w / 14.0; }
+Weight operator®""_kg®( unsigned long long int w ) { return w / 6.35; }
+int main() {
+        Weight w, heavy = { 20 }; // stones
+        w = 155®_lb®;
+        w = 0b1111®_st®;
+        w = 0'233®_lb®;         // quote separator
+        w = 0x9b®_kg®;
+        w = 5.5®_st® + 8®_kg® + 25.01®_lb® + heavy;
+}
+\end{C++}
+\end{tabular}
+\begin{comment}
+Time : comparison of time units. \\
+\begin{tabular}{@{}ll@{}}
+\CFA & \CC \\
+\begin{cfa}
+#include <fstream.hfa>
+#include <time.hfa>
+Duration s = 1`h + 2 * 10`m + 70`s / 10;
+sout | "1 hour + 2*10 min + 70/10 sec = " | s | "seconds";
+sout | "Dividing that by 2 minutes gives" | s / 2`m;
+sout | "Dividing that by 2 gives" | s / 2 | "seconds\n";
+sout | s | "seconds is"
+          | s`h | "hours,"
+          | (s % 1`h)`m | "minutes,"
+          | (s % 1`m)`s | "seconds";
+\end{cfa}
+&
+\begin{C++}
+#include <iostream>
+#include <chrono>
+using namespace std;
+using namespace std::chrono;
+seconds s = hours(1) + 2 * minutes(10) + seconds(70) / 10;
+cout << "1 hour + 2*10 min + 70/10 sec = " << s.count() << " seconds\n";
+cout << "Dividing that by 2 minutes gives " << s / minutes(2) << '\n';
+cout << "Dividing that by 2 gives " << (s / 2).count() << " seconds\n";
+cout << s.count() << " seconds is "
+          << duration_cast<hours>( s ).count() << " hours, "
+          << duration_cast<minutes>( s % hours(1) ).count() << " minutes, "
+          << duration_cast<seconds>( s % minutes(1) ).count() << " seconds\n";
+\end{C++}
+\end{tabular}
+\end{comment}
+\caption{Units: Stone, Pound, Kilogram Comparison}
+\label{f:UnitsComparison}
+\end{figure}
+The \CC example (right) provides a \emph{restricted} capability via user literals.
+The \lstinline[language=C++]{operator ""} only takes a constant argument (\ie no variable argument), and the constant type must be the highest-level constant-type, \eg ©long double© for all floating-point constants.
+As well, there is no constant conversion, \ie ©int© to ©double© constants, so integral constants are handled by a separate set of routines, with maximal integral type ©unsigned long long int©.
+Finally, there is no mechanism to use this syntax for a bidirectional conversion because \lstinline[language=C++]{operator ""} does not accept variable arguments.
 …
 \section{Tuple}
+\label{s:Tuple}
 In C and \CFA, lists of elements appear in several contexts, such as the parameter list of a routine call.
 …
 \subsection{Polymorphism}
 Due to the implicit flattening and structuring conversions involved in argument passing, ©otype© and ©dtype© parameters are restricted to matching only with non-tuple types.
+Due to the implicit flattening and structuring conversions involved in argument passing, object and opaque parameters are restricted to matching only with non-tuple types.
 The integration of polymorphism, type assertions, and monomorphic specialization of tuple-assertions are a primary contribution of this thesis to the design of tuples.
 \begin{cfa}
 forall(T, dtype U)
+forall(T, U &)
 void f(T x, U * y);
 …
 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;
 \end{cfa}
+\index{lvalue}
+The left-hand side is a tuple of \LstBasicStyle{\emph{lvalues}}, which is a list of expressions each yielding an address, \ie any data object that can appear on the left-hand side of a conventional assignment statement.
+The left-hand side is a tuple of \LstBasicStyle{\emph{\Index{lvalue}}}s, which is a list of expressions each yielding an address, \ie any data object that can appear on the left-hand side of a conventional assignment statement.
 \LstBasicStyle{\emph{expr}} is any standard arithmetic expression.
 Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
 …
 Multiple assignment has the following form:
 \begin{cfa}
+[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ];
+\end{cfa}
+\index{lvalue}
+The left-hand side is a tuple of \emph{lvalues}, and the right-hand side is a tuple of \emph{expr}s.
+Each \emph{expr} appearing on the right-hand side of a multiple assignment statement is assigned to the corresponding \emph{lvalues} on the left-hand side of the statement using parallel semantics for each assignment.
+[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ];§
+\end{cfa}
+The left-hand side is a tuple of \LstBasicStyle{\emph{\Index{lvalue}}}s, and the right-hand side is a tuple of \LstBasicStyle{\emph{expr}}s.
+Each \LstBasicStyle{\emph{expr}} appearing on the right-hand side of a multiple assignment statement is assigned to the corresponding \LstBasicStyle{\emph{lvalues}} on the left-hand side of the statement using parallel semantics for each assignment.
 An example of multiple assignment is:
 \begin{cfa}
 …
         sout | '1' | '2' | '3';
         sout | 1 | "" | 2 | "" | 3;
         sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x Â£" | 6 | "x Â¥"
                 | 7 | "x Â¡" | 8 | "x Â¿" | 9 | "x Â«" | 10;
+        sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
+                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10;
         sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
                 | 7 | "Â¢ x" | 8 | "Â» x" | 9 | ") x" | 10 | "] x" | 11 | "} x";
+                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x";
         sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx";
         sout | "x ( " | 1 | " ) x" | 2 | " , x" | 3 | " :x: " | 4;
 …
 \item[Rationale:] increase type safety
 \item[Effect on original feature:] deletion of semantically well-defined feature.
 \item[Difficulty of converting:] requires adding a cast \see{\VRef{s:StorageManagement} for better alternatives}:
+\item[Difficulty of converting:] requires adding a cast \see{\VRef{s:DynamicStorageManagement} for better alternatives}:
 \begin{cfa}
         int * b = (int *)malloc( sizeof(int) );
 …
 \section{Standard Library}
 \label{s:StandardLibrary}
+The \CFA standard-library wraps explicitly-polymorphic C routines into implicitly-polymorphic versions.
+\subsection{Storage Management}
+\label{s:StorageManagement}
+The storage-management routines extend their C equivalents by overloading, alternate names, providing shallow type-safety, and removing the need to specify the allocation size for non-array types.
+C storage management provides the following capabilities:
+\begin{description}
+\item[filled]
+after allocation with a specified character or value.
+\index{standard library}
+The \CFA standard-library extends existing C library routines by adding new function, wrapping existing explicitly-polymorphic C routines into implicitly-polymorphic versions, and adding new \CFA extensions.
+\subsection{Dynamic Storage-Management}
+\label{s:DynamicStorageManagement}
+\index{dynamic storage-management}\index{storage management}
+Dynamic storage-management in C is based on explicit allocation and deallocation (©malloc©/©free©).
+Programmer's must manage all allocated storage via its address (pointer) and subsequently deallocate the storage via this address.
+Storage that is not deallocated becomes inaccessible, called a \newterm{memory leak}, which can only be detected at program termination.
+Storage freed twice is an error, called a \newterm{duplicate free}, which can sometimes be detected.
+Storage used after it is deallocated is an error, called using a \newterm{dangling pointer}, which can sometimes be detected.
+\subsubsection{C Interface}
+C dynamic storage-management provides the following properties.
+\begin{description}[leftmargin=*]
+\item[fill]
+storage after an allocation with a specified character or value.
+\item[align]
+an allocation on a specified memory boundary, \eg, an address multiple of 64 or 128 for cache-line purposes.
+\item[scale]
+an allocation size to the specified number of array elements.
+An array may be filled, resized, or aligned.
 \item[resize]
 an existing allocation to decreased or increased its size.
+In either case, new storage may or may not be allocated and, if there is a new allocation, as much data from the existing allocation is copied into the new allocation.
+For an increase in storage size, new storage after the copied data may be filled.
+\item[align]
+an allocation on a specified memory boundary, \eg, an address multiple of 64 or 128 for cache-line purposes.
+\item[array]
+the allocation size is scaled to the specified number of array elements.
+An array may be filled, resized, or aligned.
+In either direction, new storage may or may not be allocated, but if there is a new allocation, as much data from the existing allocation is copied into the new allocation.
+When new storage is allocated, it may be aligned and storage after copied data may be filled.
 \end{description}
+\VRef[Table]{t:AllocationVersusCapabilities} shows allocation routines supporting different combinations of storage-management capabilities.
+\VRef[Table]{t:AllocationVersusProperties} shows different combinations of storage-management properties provided by the C and \CFA allocation routines.
 \begin{table}
+\caption{Allocation Routines versus Storage-Management Properties}
+\label{t:AllocationVersusProperties}
 \centering
 \begin{minipage}{0.75\textwidth}
 \begin{tabular}{@{}r|l|l|l|l|l@{}}
 \multicolumn{1}{c}{}&           & \multicolumn{1}{c|}{fill}     & resize        & alignment     & array \\
+                & \multicolumn{1}{c|}{routine} & \multicolumn{1}{c|}{\textbf{fill}} & \textbf{alignment}        & \textbf{scale}        & \textbf{resize} \\
 \hline
 C               & ©malloc©                      & no                    & no            & no            & no    \\
+                & ©calloc©                      & yes (0 only)  & no            & no            & yes   \\
+                & ©realloc©                     & copy                  & yes           & no            & no    \\
+                & ©memalign©            & no                    & no            & yes           & no    \\
+                & ©aligned_alloc©\footnote{Same as ©memalign© but size is an integral multiple of alignment, which is universally ignored.}
+                                                        & no                    & no            & yes           & no    \\
+                & ©posix_memalign©      & no                    & no            & yes           & no    \\
+                & ©valloc©                      & no                    & no            & yes (page size)& no   \\
+                & ©calloc©                      & yes (0 only)  & no            & yes           & no    \\
+                & ©realloc©                     & copy                  & no            & no            & yes   \\
+                & ©reallocarray©        & copy                  & no            & yes           & yes   \\
+                & ©memalign©            & no                    & yes           & no            & no    \\
+                & ©aligned_alloc©\footnote{Same as ©memalign© but size is an integral multiple of alignment.}
+                                                        & no                    & yes           & no            & no    \\
+                & ©posix_memalign©      & no                    & yes           & no            & no    \\
+                & ©valloc©                      & no                    & yes (page size)& no   & no    \\
                 & ©pvalloc©\footnote{Same as ©valloc© but rounds size to multiple of page size.}
+                                                        & no                    & no            & yes (page size)& no   \\
+\hline
+\CFA    & ©cmemalign©           & yes (0 only)  & no            & yes           & yes   \\
+                & ©realloc©                     & copy                  & yes           & yes           & no    \\
+                & ©alloc©                       & no                    & yes           & no            & yes   \\
+                & ©alloc_set©           & yes                   & yes           & no            & yes   \\
+                & ©alloc_align©         & no                    & yes           & yes           & yes   \\
+                & ©alloc_align_set©     & yes                   & yes           & yes           & yes   \\
+                                                        & no                    & yes (page size)& no   & no    \\
+\hline
+\CFA    & ©cmemalign©           & yes (0 only)  & yes           & yes           & no    \\
+                & ©resize©                      & no copy               & yes           & no            & yes   \\
+                & ©realloc©                     & copy                  & yes           & no            & yes   \\
+                & ©alloc©\footnote{Multiple overloads with different parameters.}
+                                                        & yes                   & yes           & yes           & yes
 \end{tabular}
 \end{minipage}
+\caption{Allocation Routines versus Storage-Management Capabilities}
+\label{t:AllocationVersusCapabilities}
+\vspace*{-10pt}
 \end{table}
+\CFA memory management extends the type safety of all allocations by using the type of the left-hand-side type to determine the allocation size and return a matching type for the new storage.
+Type-safe allocation is provided for all C allocation routines and new \CFA allocation routines, \eg in
+\begin{cfa}
+int * ip = (int *)malloc( sizeof(int) ); §\C{// C}§
+int * ip = malloc();                                    §\C{// \CFA type-safe version of C malloc}§
+int * ip = alloc();                                             §\C{// \CFA type-safe uniform alloc}§
+\end{cfa}
+the latter two allocations determine the allocation size from the type of ©p© (©int©) and cast the pointer to the allocated storage to ©int *©.
+\CFA memory management extends allocation safety by implicitly honouring all alignment requirements, \eg in
+\begin{cfa}
+struct S { int i; } __attribute__(( aligned( 128 ) )); // cache-line alignment
+S * sp = malloc();                                              §\C{// honour type alignment}§
+\end{cfa}
+the storage allocation is implicitly aligned to 128 rather than the default 16.
+The alignment check is performed at compile time so there is no runtime cost.
+\CFA memory management extends the resize capability with the notion of \newterm{sticky properties}.
+Hence, initial allocation capabilities are remembered and maintained when resize requires copying.
+For example, an initial alignment and fill capability are preserved during a resize copy so the copy has the same alignment and extended storage is filled.
+Without sticky properties it is dangerous to use ©realloc©, resulting in an idiom of manually performing the reallocation to maintain correctness.
+\begin{cfa}
+\end{cfa}
+\CFA memory management extends allocation to support constructors for initialization of allocated storage, \eg in
+\begin{cfa}
+struct S { int i; };                                    §\C{// cache-line alignment}§
+void ?{}( S & s, int i ) { s.i = i; }
+// assume ?|? operator for printing an S
+S & sp = *®new®( 3 );                                   §\C{// call constructor after allocation}§
+sout | sp.i;
+®delete®( &sp );
+S * spa = ®anew®( 10, 5 );                              §\C{// allocate array and initialize each array element}§
+for ( i; 10 ) sout | spa[i] | nonl;
+sout | nl;
+®adelete®( 10, spa );
+\subsubsection{\CFA Interface}
+\CFA dynamic memory management:
+\begin{enumerate}[leftmargin=\parindent]
+\item
+extends type safety of all allocation routines by using the left-hand assignment type to determine the allocation size and alignment, and return a matching type for the new storage, which removes many common allocation errors.
+\begin{cfa}
+int * ip = (int *)malloc( sizeof(int) ); §\C[2.3in]{// C}§
+int * ip = malloc();                                    §\C{// \CFA type-safe call of C malloc}§
+int * ip = calloc();                                    §\C{// \CFA type-safe call of C calloc}§
+struct __attribute__(( aligned(128) )) spinlock { ... }; // cache alignment
+spinlock * slp = malloc();                              §\C{// correct size, alignment, and return type}\CRT§
+\end{cfa}
+Here, the alignment of the ©ip© storage is 16 (default) and 128 for ©slp©.
+\item
+introduces the notion of \newterm{sticky properties} used in resizing.
+All initial allocation properties are remembered and maintained for use should resize require new storage.
+For example, the initial alignment and fill properties in the initial allocation
+\begin{cfa}
+struct __attribute__(( aligned(4096) )) S { ... };
+S * sp = calloc( 10 );                                  §\C{// align 4K and zero fill}§
+sp = reallocarray( sp, 100 );                   §\C{// preserve 4K alignment and zero fill new storage}§
+\end{cfa}
+are preserved in the resize so the new storage has the same alignment and extra storage after the data copy is zero filled.
+Without sticky properties it is dangerous to resize, resulting in the C idiom of manually performing the reallocation to maintain correctness, which is error prone.
+\item
+provides resizing without data copying, which is useful to repurpose an existing block of storage, rather than freeing the old storage and performing a new allocation.
+A resize can take advantage of unused storage after the data to preventing a free/reallocation step altogether.
+\item
+provides ©free©/©delete© functions that delete a variable number of allocations.
+\begin{cfa}
+int * ip = malloc(), * jp = malloc(), * kp = malloc();
+double * xp = malloc(), * yp = malloc(), * zp = malloc();
+free( ®ip, jp, kp, xp, yp, zp® );               §\C{// multiple deallocations}§
+\end{cfa}
+\item
+supports constructors for initialization of allocated storage and destructors for deallocation (like \CC).
+\begin{cfa}
+struct S { int v; };                                    §\C{// default constructors}§
+void ^?{}( S & ) { ... }                                §\C{// destructor}§
+S & sp = *®new®( 3 );                                   §\C{// allocate and call constructor}§
+sout | sp.v;
+®delete®( &sp );                                                §\C{// call destructor}§
+S * spa1 = ®anew®( 10, 5 ), * spa2 = ®anew®( 10, 8 ); §\C{// allocate array and call constructor for each array element}§
+for ( i; 10 ) sout | spa1[i].v | spa2[i].v | nonl; sout | nl;
+®adelete®( spa1, spa2 );                                §\C{// call destructors on all array objects}§
+8 5 8 5 8 5 8 5 8 5 8 5 8 5 8 5 8 5 8
 \end{cfa}
 Allocation routines ©new©/©anew© allocate a variable/array and initialize storage using the allocated type's constructor.
 Note, the matching deallocation routines ©delete©/©adelete©.
+\leavevmode
+\CC only supports the default constructor for intializing array elements.
+\begin{C++}
+S * sp = new S[10]®{5}®;                                §\C{// disallowed}§
+\end{C++}
+\end{enumerate}
+In addition, \CFA provides a new allocator interface to further increase orthogonality and usability of dynamic-memory allocation.
+This interface helps programmers in three ways.
+\begin{enumerate}
+\item
+naming: \CFA regular and ©ttype© polymorphism (similar to \CC variadic templates) is used to encapsulate a wide range of allocation functionality into a single routine name, so programmers do not have to remember multiple routine names for different kinds of dynamic allocations.
+\item
+named arguments: individual allocation properties are specified using postfix function call \see{\VRef{s:PostfixFunction}}, so programmers do not have to remember parameter positions in allocation calls.
+\item
+safe usage: like the \CFA's C-interface, programmers do not have to specify object size or cast allocation results.
+\end{enumerate}
+The polymorphic functions
+\begin{cfa}
+T * alloc( ... );
+T * alloc( size_t dim, ... );
+\end{cfa}
+are overloaded with a variable number of allocation properties.
+These allocation properties can be passed as named arguments when calling the \Indexc{alloc} routine.
+A call without parameters returns an uninitialized dynamically allocated object of type ©T© (\Indexc{malloc}).
+A call with only the dimension (dim) parameter returns an uninitialized dynamically allocated array of objects with type ©T© (\Indexc{aalloc}).
+The variable number of arguments consist of allocation properties to specialize the allocation.
+The properties ©resize© and ©realloc© are associated with an existing allocation variable indicating how its storage is modified.
+The following allocation property functions may be combined and appear in any order as arguments to ©alloc©,
+\begin{itemize}
+\item
+©T_align ?`align( size_t alignment )© to align an allocation.
+The alignment parameter must be $\ge$ the default alignment (©libAlign()© in \CFA) and a power of two, \eg the following return a dynamic object and object array aligned on a 256 and 4096-byte boundary.
+\begin{cfa}
+int * i0 = alloc( ®256`align® );  sout | i0 | nl;
+int * i1 = alloc( 3, ®4096`align® );  for (i; 3 ) sout | &i1[i] | nonl;  sout | nl;
+free( i0, i1 );
+x5555565699®00®  // 256 alignment
+x55555656c®000® 0x5656c004 0x5656c008  // 4K array alignment
+\end{cfa}
+\item
+©T_fill(T) ?`fill( /* various types */ )© to initialize storage.
+There are three ways to fill storage:
+\begin{enumerate}
+\item
+A ©char© fills every byte of each object.
+\item
+An object of the returned type fills each object.
+\item
+An object array pointer fills some or all of the corresponding object array.
+\end{enumerate}
+For example:
+\begin{cfa}[numbers=left]
+int * i0 = alloc( ®0n`fill® );  sout | *i0 | nl;  // 0n disambiguates 0p
+int * i1 = alloc( ®5`fill® );  sout | *i1 | nl;
+int * i2 = alloc( ®'\xfe'`fill® ); sout | hex( *i2 ) | nl;
+int * i3 = alloc( 5, ®5`fill® );  for ( i; 5 ) sout | i3[i] | nonl; sout | nl;
+int * i4 = alloc( 5, ®0xdeadbeefN`fill® );  for ( i; 5 ) sout | hex( i4[i] ) | nonl; sout | nl;
+int * i5 = alloc( 5, ®i3`fill® );  for ( i; 5 ) sout | i5[i] | nonl; sout | nl; // completely fill from i3
+int * i6 = alloc( 5, ®[i3, 3]`fill® );  for ( i; 5 ) sout | i6[i] | nonl; sout | nl; // partial fill from i3
+free( i0, i1, i2, i3, i4, i5, i6 );
+\end{cfa}
+\begin{lstlisting}[numbers=left]
+xfefefefe
+5 5 5 5
+xdeadbeef 0xdeadbeef 0xdeadbeef 0xdeadbeef 0xdeadbeef
+5 5 5 5
+5 5 -555819298 -555819298  // two undefined values
+\end{lstlisting}
+Examples 1 to 3 fill an object with a value or characters.
+Examples 4 to 7 fill an array of objects with values, another array, or part of an array.
+\item
+©S_resize(T) ?`resize( void * oaddr )© used to resize, realign, and fill, where the old object data is not copied to the new object.
+The old object type may be different from the new object type, since the values are not used.
+For example:
+\begin{cfa}[numbers=left]
+int * ip = alloc( ®5`fill® );  sout | ip | *ip;
+ip = alloc( ®ip`resize®, ®256`align®, ®7`fill® );  sout | ip | *ip;
+double * dp = alloc( ®ip`resize®, ®4096`align®, ®13.5`fill® );  sout | dp | *dp;
+free( dp );  // DO NOT FREE ip AS ITS STORAGE IS MOVED TO dp
+\end{cfa}
+\begin{lstlisting}[numbers=left]
+x555555580a80 5
+x555555581100 7
+x555555587000 13.5
+\end{lstlisting}
+Examples 2 to 3 change the alignment, fill, and size for the initial storage of ©i©.
+\begin{cfa}[numbers=left]
+int * ia = alloc( 5, ®5`fill® );  sout | ia | nonl;  for ( i; 5 ) sout | ia[i] | nonl; sout | nl;
+ia = alloc( 10, ®ia`resize®, ®7`fill® );  sout | ia | nonl;  for ( i; 10 ) sout | ia[i] | nonl; sout | nl;
+ia = alloc( 5, ®ia`resize®, ®512`align®, ®13`fill® ); sout | ia | nonl; for ( i; 5 ) sout | ia[i] | nonl; sout | nl;;
+ia = alloc( 3, ®ia`resize®, ®4096`align®, ®2`fill® );  for ( i; 3 ) sout | &ia[i] | ia[i] | nonl; sout | nl;
+free( ia );
+\end{cfa}
+\begin{lstlisting}[numbers=left]
+x55555656d540 5 5 5 5 5
+x55555656d480 7 7 7 7 7 7 7 7 7 7
+x55555656fe00 13 13 13 13 13
+x555556570000 2 0x555556570004 2 0x555556570008 2
+\end{lstlisting}
+Examples 2 to 4 change the array size, alignment, and fill initializes all storage because no data is copied.
+\item
+©S_realloc(T) ?`realloc( T * a ))©
+used to resize, realign, and fill, where the old object data is copied to the new object.
+The old object type must be the same as the new object type, since the value is used.
+Note, for ©fill©, only the extra space after copying the data from the old object is filled with the given parameter.
+For example:
+\begin{cfa}[numbers=left]
+int * ip = alloc( ®5`fill® );  sout | ip | *ip;
+ip = alloc( ®ip`realloc®, ®256`align® );  sout | ip | *ip;
+ip = alloc( ®ip`realloc®, ®4096`align®, ®13`fill® );  sout | ip | *ip;
+free( ip );
+\end{cfa}
+\begin{lstlisting}[numbers=left]
+x55555556d5c0 5
+x555555570000 5
+x555555571000 5
+\end{lstlisting}
+Examples 2 to 3 change the alignment for the initial storage of ©i©.
+The ©13`fill© in example 3 does nothing because no new storage is added.
+\begin{cfa}[numbers=left]
+int * ia = alloc( 5, ®5`fill® );  sout | ia | nonl;  for ( i; 5 ) sout | ia[i] | nonl; sout | nl;
+ia = alloc( 10, ®ia`realloc®, ®7`fill® );  sout | ia | nonl;  for ( i; 10 ) sout | ia[i] | nonl; sout | nl;
+ia = alloc( 5, ®ia`realloc®, ®512`align®, ®13`fill® );  sout | ia | nonl; for ( i; 5 ) sout | ia[i] | nonl; sout | nl;;
+ia = alloc( 3, ®ia`realloc®, ®4096`align®, ®2`fill® );  for ( i; 3 ) sout | &ia[i] | ia[i] | nonl; sout | nl;
+free( ia );
+\end{cfa}
+\begin{lstlisting}[numbers=left]
+x55555656d540 5 5 5 5 5
+x55555656d480 7 7 7 7 7 7 7 7 7 7
+x555556570e00 5 5 5 5 5
+x5555556571000 5 0x555556571004 5 0x555556571008 5
+\end{lstlisting}
+Examples 2 to 4 change the array size, alignment, and fill does no initialization after the copied data, as no new storage is added.
+\end{itemize}
+\medskip
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 extern "C" {
+        // C unsafe allocation
+        void * malloc( size_t size );§\indexc{malloc}§
+        void * calloc( size_t dim, size_t size );§\indexc{calloc}§
+        void * realloc( void * ptr, size_t size );§\indexc{realloc}§
+        void * memalign( size_t align, size_t size );§\indexc{memalign}§
+        void * aligned_alloc( size_t align, size_t size );§\indexc{aligned_alloc}§
+        int posix_memalign( void ** ptr, size_t align, size_t size );§\indexc{posix_memalign}§
+        void * cmemalign( size_t alignment, size_t noOfElems, size_t elemSize );§\indexc{cmemalign}§ // CFA
+        // C unsafe initialization/copy
+        void * memset( void * dest, int c, size_t size );§\indexc{memset}§
+        void * memcpy( void * dest, const void * src, size_t size );§\indexc{memcpy}§
+}
+void * realloc( void * oaddr, size_t nalign, size_t size ); // CFA heap
+forall( dtype T | sized(T) ) {
+        // §\CFA§ safe equivalents, i.e., implicit size specification
+        T * malloc( void );
+        T * calloc( size_t dim );
+        T * realloc( T * ptr, size_t size );
+        T * memalign( size_t align );
+        T * cmemalign( size_t align, size_t dim  );
+        T * aligned_alloc( size_t align );
+        int posix_memalign( T ** ptr, size_t align );
+        // New C allocation operations.
+        void * aalloc( size_t dim, size_t elemSize );§\indexc{aalloc}§
+        void * resize( void * oaddr, size_t size );§\indexc{resize}§
+        void * amemalign( size_t align, size_t dim, size_t elemSize );§\indexc{amemalign}§
+        void * cmemalign( size_t align, size_t dim, size_t elemSize );§\indexc{cmemalign}§
+        size_t malloc_alignment( void * addr );§\indexc{malloc_alignment}§
+        bool malloc_zero_fill( void * addr );§\indexc{malloc_zero_fill}§
+        size_t malloc_size( void * addr );§\indexc{malloc_size}§
+        int malloc_stats_fd( int fd );§\indexc{malloc_stats_fd}§
+        size_t malloc_expansion();§\indexc{malloc_expansion}§ §\C{// heap expansion size (bytes)}§
+        size_t malloc_mmap_start();§\indexc{malloc_mmap_start}§ §\C{// crossover allocation size from sbrk to mmap}§
+        size_t malloc_unfreed();§\indexc{malloc_unfreed()}§     §\C{// heap unfreed size (bytes)}§
+        void malloc_stats_clear();§\indexc{malloc_stats_clear}§ §\C{// clear heap statistics}§
+}
+// New allocation operations.
+void * resize( void * oaddr, size_t alignment, size_t size );
+void * realloc( void * oaddr, size_t alignment, size_t size );
+void * reallocarray( void * oaddr, size_t nalign, size_t dim, size_t elemSize );
+forall( T & | sized(T) ) {
+        // §\CFA§ safe equivalents, i.e., implicit size specification, eliminate return-type cast
+        T * malloc( void );§\indexc{malloc}§
+        T * aalloc( size_t dim );§\indexc{aalloc}§
+        T * calloc( size_t dim );§\indexc{calloc}§
+        T * resize( T * ptr, size_t size );§\indexc{resize}§
+        T * resize( T * ptr, size_t alignment, size_t size );
+        T * realloc( T * ptr, size_t size );§\indexc{realloc}§
+        T * realloc( T * ptr, size_t alignment, size_t size );
+        T * reallocarray( T * ptr, size_t dim );§\indexc{reallocarray}§
+        T * reallocarray( T * ptr, size_t alignment, size_t dim );
+        T * memalign( size_t align );§\indexc{memalign}§
+        T * amemalign( size_t align, size_t dim );§\indexc{amemalign}§
+        T * cmemalign( size_t align, size_t dim );§\indexc{aalloc}§
+        T * aligned_alloc( size_t align );§\indexc{aligned_alloc}§
+        int posix_memalign( T ** ptr, size_t align );§\indexc{posix_memalign}§
+        T * valloc( void );§\indexc{valloc}§
+        T * pvalloc( void );§\indexc{pvalloc}§
         // §\CFA§ safe general allocation, fill, resize, alignment, array
+        T * alloc( void );§\indexc{alloc}§                                      §\C[3.5in]{// variable, T size}§
+        T * alloc( size_t dim );                                                        §\C{// array[dim], T size elements}§
+        T * alloc( T ptr[], size_t dim );                                       §\C{// realloc array[dim], T size elements}§
+        T * alloc_set( char fill );§\indexc{alloc_set}§         §\C{// variable, T size, fill bytes with value}§
+        T * alloc_set( T fill );                                                        §\C{// variable, T size, fill with value}§
+        T * alloc_set( size_t dim, char fill );                         §\C{// array[dim], T size elements, fill bytes with value}§
+        T * alloc_set( size_t dim, T fill );                            §\C{// array[dim], T size elements, fill elements with value}§
+        T * alloc_set( size_t dim, const T fill[] );            §\C{// array[dim], T size elements, fill elements with array}§
+        T * alloc_set( T ptr[], size_t dim, char fill );        §\C{// realloc array[dim], T size elements, fill bytes with value}§
+        T * alloc_align( size_t align );                                        §\C{// aligned variable, T size}§
+        T * alloc_align( size_t align, size_t dim );            §\C{// aligned array[dim], T size elements}§
+        T * alloc_align( T ptr[], size_t align );                       §\C{// realloc new aligned array}§
+        T * alloc_align( T ptr[], size_t align, size_t dim ); §\C{// realloc new aligned array[dim]}§
+        T * alloc_align_set( size_t align, char fill );         §\C{// aligned variable, T size, fill bytes with value}§
+        T * alloc_align_set( size_t align, T fill );            §\C{// aligned variable, T size, fill with value}§
+        T * alloc_align_set( size_t align, size_t dim, char fill ); §\C{// aligned array[dim], T size elements, fill bytes with value}§
+        T * alloc_align_set( size_t align, size_t dim, T fill ); §\C{// aligned array[dim], T size elements, fill elements with value}§
+        T * alloc_align_set( size_t align, size_t dim, const T fill[] ); §\C{// aligned array[dim], T size elements, fill elements with array}§
+        T * alloc_align_set( T ptr[], size_t align, size_t dim, char fill ); §\C{// realloc new aligned array[dim], fill new bytes with value}§
+        // §\CFA§ safe initialization/copy, i.e., implicit size specification
+        T * memset( T * dest, char fill );§\indexc{memset}§
+        T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
+        // §\CFA§ safe initialization/copy, i.e., implicit size specification, array types
+        T * amemset( T dest[], char fill, size_t dim );
+        T * alloc( ... );§\indexc{alloc}§                                       §\C{// variable, T size}§
+        T * alloc( size_t dim, ... );
+        T_align ?`align( size_t alignment );§\indexc{align}§
+        T_fill(T) ?`fill( /* various types */ );§\indexc{fill}§
+        T_resize ?`resize( void * oaddr );§\indexc{resize}§
+        T_realloc ?`realloc( void * oaddr ));§\indexc{realloc}§
+}
+forall( T &, List ... ) void free( T * ptr, ... ) // deallocation list
+// §\CFA§ allocation/deallocation and constructor/destructor, non-array types
+forall( T &, Parms ... | { void ?{}( T &, Parms ); } ) T * new( Parms ... );§\indexc{new}§
+forall( T &, List ... | { void ^?{}( T & ); void delete( List ... ); } );§\indexc{delete}§
+// §\CFA§ allocation/deallocation and constructor/destructor, array types
+forall( T & | sized(T), Parms ... | { void ?{}( T &, Parms ); } ) T * anew( size_t dim, Parms ... );§\indexc{anew}§
+forall( T & | sized(T) | { void ^?{}( T & ); }, List ... } ) void adelete( T arr[], List ... );§\indexc{adelete}§
+\end{cfa}
+\subsection{Memory Set and Copy}
+Like safe memory allocation, \CFA provides safe block initialization and copy.
+While objects should be initialized/copied with constructors/assignment, block operations can be very performant.
+In certain cases the compiler generates block copy operations, such as assigning structures ©s = t©, however C arrays cannot be assigned.
+\begin{cquote}
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
+struct S { int i, j, k; };
+S s, t, *sp = &s, * tp = &t, sa[10], ta[10];
+\end{cfa}
+\noindent
+\begin{tabular}{@{}l|l@{}}
+\multicolumn{1}{@{}c|}{\textbf{\CFA}} & \multicolumn{1}{c@{}}{\textbf{C}} \\
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
+memset( s, '\0' );
+memset( sp, '\0' );
+memcpy( s, t );
+memcpy( sp, tp );
+amemset( sa, '\0', 10 );
+amemcpy( sa, ta, 10 );
+\end{cfa}
+&
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
+memset( &s, '\0', sizeof(s) );
+memset( sp, '\0', sizeof(s) );
+memcpy( &s, &t, sizeof(s) );
+memcpy( sp, tp, sizeof(s) );
+memset( sa, '\0', sizeof(sa) );
+memcpy( sa, ta, sizeof(sa) );
+\end{cfa}
+\end{tabular}
+\end{cquote}
+These operations provide uniformity between reference and pointer, so object dereferencing, '©&©', is unnecessary.
+\begin{cfa}
+static inline forall( T & | sized(T) ) {
+        // CFA safe initialization/copy, i.e., implicit size specification, non-array types
+        T * memset( T * dest, char fill );§\indexc{memset}§     §\C{// all combinations of pointer/reference}§
+        T * memset( T & dest, char fill );
+        T * memcpy( T * dest, const T * src );§\indexc{memcpy}§ §\C{// all combinations of pointer/reference}§
+        T * memcpy( T & dest, const T & src );
+        T * memcpy( T * dest, const T & src );
+        T * memcpy( T & dest, const T * src );
+        // CFA safe initialization/copy, i.e., implicit size specification, array types
+        T * amemset( T dest[], char fill, size_t dim );§\indexc{memcpy}§
         T * amemcpy( T dest[], const T src[], size_t dim );
+}
-// §\CFA§ allocation/deallocation and constructor/destructor, non-array types
-forall( dtype T | sized(T), ttype Params | { void ?{}( T &, Params ); } ) T * new( Params p );§\indexc{new}§
-forall( dtype T | sized(T) | { void ^?{}( T & ); } ) void delete( T * ptr );§\indexc{delete}§
-forall( dtype T, ttype Params | sized(T) | { void ^?{}( T & ); void delete( Params ); } )
-  void delete( T * ptr, Params rest );
-// §\CFA§ allocation/deallocation and constructor/destructor, array types
-forall( dtype T | sized(T), ttype Params | { void ?{}( T &, Params ); } ) T * anew( size_t dim, Params p );§\indexc{anew}§
-forall( dtype T | sized(T) | { void ^?{}( T & ); } ) void adelete( size_t dim, T arr[] );§\indexc{adelete}§
-forall( dtype T | sized(T) | { void ^?{}( T & ); }, ttype Params | { void adelete( Params ); } )
-  void adelete( size_t dim, T arr[], Params rest );
 \end{cfa}
 …
 Int sqrt( Int oper );
 forall( dtype istype | istream( istype ) ) istype * ?|?( istype * is, Int * mp );  §\C{// I/O}§
 forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype * os, Int mp );
+forall( istype & | istream( istype ) ) istype * ?|?( istype * is, Int * mp );  §\C{// I/O}§
+forall( ostype & | ostream( ostype ) ) ostype * ?|?( ostype * os, Int mp );
 \end{cfa}
 \VRef[Figure]{f:MultiPrecisionFactorials} shows \CFA and C factorial programs using the GMP interfaces.
 …
 \begin{cquote}
 \begin{tabular}{@{}l@{\hspace{\parindentlnth}}|@{\hspace{\parindentlnth}}l@{}}
 \multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{C}}    & \multicolumn{1}{@{\hspace{\parindentlnth}}c@{}}{\textbf{\CFA}}        \\
+\multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{@{\hspace{\parindentlnth}}c@{}}{\textbf{C}}   \\
 \hline
+\begin{cfa}
+#include <gmp.hfa>§\indexc{gmp}§
+int main( void ) {
+        sout | "Factorial Numbers";
+        ®Int® fact = 1;
+        sout | 0 | fact;
+        for ( i; 40 ) {
+                fact *= i;
+                sout | i | fact;
+        }
+}
+\end{cfa}
+&
 \begin{cfa}
 #include <gmp.h>§\indexc{gmp.h}§
 …
                 ®mpz_mul_ui®( fact, fact, i );
                 ®gmp_printf®( "%d %Zd\n", i, fact );
+        }
+}
-\end{cfa}
+&
-\begin{cfa}
-#include <gmp.hfa>§\indexc{gmp}§
-int main( void ) {
-        sout | "Factorial Numbers";
-        Int fact = 1;
-        sout | 0 | fact;
-        for ( i; 40 ) {
-                fact *= i;
-                sout | i | fact;
+        }
+}
 …
 Rational narrow( double f, long int md );
 forall( dtype istype | istream( istype ) ) istype * ?|?( istype *, Rational * ); // I/O
 forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype *, Rational );
+forall( istype & | istream( istype ) ) istype * ?|?( istype *, Rational * ); // I/O
+forall( ostype & | ostream( ostype ) ) ostype * ?|?( ostype *, Rational );
 \end{cfa}
 …
 \end{document}
+From: Michael Leslie Brooks <mlbrooks@uwaterloo.ca>
+To: Peter Buhr <pabuhr@uwaterloo.ca>,
+        Andrew James Beach
+        <ajbeach@uwaterloo.ca>,
+        Fangren Yu <f37yu@uwaterloo.ca>, Jiada Liang
+        <j82liang@uwaterloo.ca>
+Subject: The White House on Memory-Safe programming
+Date: Mon, 4 Mar 2024 16:49:53 +0000
+I heard tell of this announcement last night.  Haven't read the actual report yet.
+Most mainstream article I can find:  https://me.pcmag.com/en/security/22413/white-house-to-developers-using-c-or-c-invites-cybersecurity-risks
+Less fluffy summary:  https://www.developer-tech.com/news/2024/feb/27/white-house-urges-adoption-memory-safe-programming-languages/
+Horse's Mouth:  https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf
+"This report focuses on the programming language as a primary building block, and explores hardware architecture and formal methods as complementary approaches"
+A contrary analysis:  https://hackaday.com/2024/02/29/the-white-house-memory-safety-appeal-is-a-security-red-herring/
 % Local Variables: %
 % tab-width: 4 %

Context Navigation

Legend:

doc/LaTeXmacros/common.sty

doc/LaTeXmacros/common.tex

doc/LaTeXmacros/lstlang.sty

doc/bibliography/pl.bib

doc/theses/jiada_liang_MMath/CFAenum.tex

doc/theses/jiada_liang_MMath/Makefile

doc/theses/jiada_liang_MMath/background.tex

doc/theses/jiada_liang_MMath/intro.tex

doc/theses/jiada_liang_MMath/relatedwork.tex

doc/theses/jiada_liang_MMath/uw-ethesis.bib

doc/theses/jiada_liang_MMath/uw-ethesis.tex

doc/uC++toCFA/Makefile

doc/uC++toCFA/uC++toCFA.tex

doc/user/Makefile

doc/user/user.tex

Download in other formats: