Index: doc/LaTeXmacros/common.sty
===================================================================
--- doc/LaTeXmacros/common.sty	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/LaTeXmacros/common.sty	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -11,6 +11,6 @@
 %% 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
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -108,8 +108,11 @@
 \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.
@@ -152,6 +155,6 @@
 \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>}
@@ -202,6 +205,7 @@
 
 \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
@@ -345,4 +349,6 @@
 \fi%
 
+\usepackage{tabularx}					% if @ is used for lstMakeShortInline, allows @{}
+
 % Local Variables: %
 % tab-width: 4 %
Index: doc/LaTeXmacros/common.tex
===================================================================
--- doc/LaTeXmacros/common.tex	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/LaTeXmacros/common.tex	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -11,6 +11,6 @@
 %% 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
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -109,8 +109,11 @@
 \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.
@@ -153,6 +156,6 @@
 \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>}
@@ -201,12 +204,13 @@
 \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}{%
@@ -349,4 +353,6 @@
 \fi%
 
+\usepackage{tabularx}					% if @ is used for lstMakeShortInline, allows @{}
+
 % Local Variables: %
 % tab-width: 4 %
Index: doc/LaTeXmacros/lstlang.sty
===================================================================
--- doc/LaTeXmacros/lstlang.sty	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/LaTeXmacros/lstlang.sty	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -8,6 +8,6 @@
 %% 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
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -116,5 +116,5 @@
 		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,
Index: doc/bibliography/pl.bib
===================================================================
--- doc/bibliography/pl.bib	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/bibliography/pl.bib	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -519,4 +519,14 @@
     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}},
 }
 
Index: doc/theses/jiada_liang_MMath/CFAenum.tex
===================================================================
--- doc/theses/jiada_liang_MMath/CFAenum.tex	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/theses/jiada_liang_MMath/CFAenum.tex	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -137,5 +137,5 @@
 \section{Pure Enumerators}
 
-An empty enumerator type, @enum()@, implies the enumerators are pure symbols without values but set properties;
+An empty enumerator type, @enum()@, implies the enumerators are opaque symbols without values but set properties;
 hence, there is no default conversion to @int@. 
 
Index: doc/theses/jiada_liang_MMath/Makefile
===================================================================
--- doc/theses/jiada_liang_MMath/Makefile	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/theses/jiada_liang_MMath/Makefile	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -13,6 +13,6 @@
 BibSRC = ${wildcard *.bib}
 
-TeXLIB = .:${LaTMac}:${Build}:
-BibLIB = .:${BibRep}:
+TeXLIB = .:${LaTMac}:${Build}:			# common latex macros
+BibLIB = .:${BibRep}:				# common citation repository
 
 MAKEFLAGS = --no-print-directory # --silent
Index: doc/theses/jiada_liang_MMath/background.tex
===================================================================
--- doc/theses/jiada_liang_MMath/background.tex	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/theses/jiada_liang_MMath/background.tex	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -48,6 +48,29 @@
 
 \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, };
Index: doc/theses/jiada_liang_MMath/intro.tex
===================================================================
--- doc/theses/jiada_liang_MMath/intro.tex	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/theses/jiada_liang_MMath/intro.tex	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -1,13 +1,15 @@
 \chapter{Introduction}
 
-All types in a programming language must have a set of constants, and these constants have \Newterm{primary names}, \eg integral types have constants @-1@, @17@, @12345@, \etc.
-Constants can be overloaded among types, \eg @0@ is a null pointer for all pointer types, and the value zero for integral and floating-point types.
+All types in a programming language must have a set of constants, and these constants have \Newterm{primary names}, \eg integral types have constants @-1@, @17@, @0xff@, floating-point types have constants @5.3@, @2.3E-5@, @0xff.ffp0@, character types have constants @'a'@, @"abc\n"@, \mbox{\lstinline{u8"}\texttt{\guillemotleft{na\"{i}ve}\guillemotright}\lstinline{"}}, \etc.
+Con\-stants can be overloaded among types, \eg @0@ is a null pointer for all pointer types, and the value zero for integral and floating-point types.
+(In \CFA, the primary constants @0@ and @1@ can be overloaded for any type.)
 Hence, each primary constant has a symbolic name referring to its internal representation, and these names are dictated by language syntax related to types.
 In theory, there are an infinite set of primary names per type.
 
-\Newterm{Secondary naming} is a common practice in mathematics and engineering, \eg $\pi$, $\tau$ (2$\pi$), $\phi$ (golden ratio), MHz (1E6), and in general situations, \eg specific times (noon, New Years), cities (Big Apple), flowers (Lily), \etc.
+\Newterm{Secondary naming} is a common practice in mathematics, engineering and computer science, \eg $\pi$, $\tau$ (2$\pi$), $\phi$ (golden ratio), MB (mega byte, 1E6), and in general situations, \eg specific times (noon, New Years), cities (Big Apple), flowers (Lily), \etc.
 Many programming languages capture this important software-engineering capability through a mechanism called \Newterm{constant} or \Newterm{literal} naming, where a secondary name is aliased to a primary name.
-In some cases, secondary naming is \Newterm{pure}, where the matching internal representation can be chosen arbitrarily, and only equality operations are available, \eg @O_RDONLY@, @O_WRONLY@, @O_CREAT@, @O_TRUNC@, @O_APPEND@.
-(The names the thing.)
+Its common purpose is to eliminate duplication of the primary constant throughout a program.
+For example, the secondary name replaces its primary name, thereafter changing the binding of the secondary to primary name automatically distributes the rebinding throughout the program.
+In some cases, secondary naming is \Newterm{opaque}, where the matching internal representation can be chosen arbitrarily, and only equality operations are available, \eg @O_RDONLY@, @O_WRONLY@, @O_CREAT@, @O_TRUNC@, @O_APPEND@.
 Because a secondary name is a constant, it cannot appear in a mutable context, \eg \mbox{$\pi$ \lstinline{= 42}} is meaningless, and a constant has no address, \ie it is an \Newterm{rvalue}\footnote{
 The term rvalue defines an expression that can only appear on the right-hand side of an assignment expression.}.
@@ -18,10 +20,8 @@
 enumerate (verb, transitive).
 To count, ascertain the number of;
-\emph{more
-usually, to mention (a number of things or persons) separately, as if for the
-purpose of counting};
-to specify as in a list or catalogue.~\cite{OED}
+more usually, to mention (a number of things or persons) separately, as if for the purpose of counting;
+to specify as in a list or catalogue.~\cite{OEDenumerate}
 \end{quote}
-Within an enumeration set, the enumeration names must be unique, and instances of an enumerated type are restricted to hold only the secondary names.
+Within an enumeration set, the enumeration names must be unique, and instances of an enumerated type are \emph{often} restricted to hold only the secondary names.
 It is possible to enumerate among set names without having an ordering among the set elements.
 For example, the week, the weekdays, the weekend, and every second day of the week.
@@ -29,8 +29,8 @@
 for ( cursor in Mon, Tue, Wed, Thu, Fri, Sat, Sun } ... $\C[3.75in]{// week}$
 for ( cursor in Mon, Tue, Wed, Thu, Fri } ...	$\C{// weekday}$
-for ( cursor in Thu, Fri } ...					$\C{// weekend}$
+for ( cursor in Sat, Sun } ...					$\C{// weekend}$
 for ( cursor in Mon, Wed, Fri, Sun } ...		$\C{// every second day of week}\CRT$
 \end{cfa}
-This independence from internal representation allows multiple names to have the same representation (eight note, quaver), giving synonyms.
+This independence from internal representation allows multiple names to have the same representation (eighth note, quaver), giving synonyms.
 A set can have a partial or total ordering, making it possible to compare set elements, \eg Monday is before Friday and Friday is after.
 Ordering allows iterating among the enumeration set using relational operators and advancement, \eg
@@ -38,10 +38,26 @@
 for ( cursor = Monday; cursor @<=@ Friday; cursor = @succ@( cursor ) ) ...
 \end{cfa}
-Here the internal representations for the secondary names are \emph{generated} rather than listing a subset of names.
+Here the internal representations for the secondary names are logically \emph{generated} rather than listing a subset of names.
+
+Hence, the fundamental aspects of an enumeration are:
+\begin{enumerate}
+\item
+It defines a type from which instants can be generated.
+\item
+The type lists a finite set of secondary names, which become its primary constants.
+This differentiates an enumeration from general types with an infinite number of primary constants.
+\item
+An enumeration's secondary names represent constants, which follows from their binding (aliasing) to primary names, which are constants.
+\item
+For safety, an enumeration instance is restricted to hold only its type's secondary names.
+\item
+There is a mechanism for \emph{enumerating} over the secondary names, where the ordering can be implicit from the type, explicitly listed, or generated arithmetically.
+\end{enumerate}
 
 
 \section{Terminology}
-
-The term \Newterm{enumeration} defines the set of secondary names, and the term \Newterm{enumerator} represents an arbitrary secondary name.
+\label{s:Terminology}
+
+The term \Newterm{enumeration} defines a type with a set of secondary names, and the term \Newterm{enumerator} represents an arbitrary secondary name \see{\VRef{s:CEnumeration}}.
 As well, an enumerated type has three fundamental properties, \Newterm{label}, \Newterm{order}, and \Newterm{value}.
 \begin{cquote}
@@ -72,26 +88,24 @@
 \section{Motivation}
 
-Some programming languages only provide secondary renaming, which can be simulated by an enumeration without ordering.
-\begin{cfa}
-const Size = 20, Pi = 3.14159;
-enum { Size = 20, Pi = 3.14159 };   // unnamed enumeration $\(\Rightarrow\)$ no ordering
-\end{cfa}
-In both cases, it is possible to compare the secondary names, \eg @Size < Pi@, if that is meaningful;
-however, without an enumeration type-name, it is impossible to create an iterator cursor.
-
-Secondary renaming can similate an enumeration, but with extra effort.
+Some programming languages only provide direct secondary renaming.
+\begin{cfa}
+const Size = 20, Pi = 3.14159, Name = "Jane";
+\end{cfa}
+Here, it is possible to compare the secondary names, \eg @Size < Pi@, if that is meaningful.
+
+Secondary renaming can simulate an enumeration, but with extra effort.
 \begin{cfa}
 const Mon = 1, Tue = 2, Wed = 3, Thu = 4, Fri = 5, Sat = 6, Sun = 7;
 \end{cfa}
-Furthermore, reordering the enumerators requires manual renumbering.
+Any reordering of the enumerators requires manual renumbering.
 \begin{cfa}
 const Sun = 1, Mon = 2, Tue = 3, Wed = 4, Thu = 5, Fri = 6, Sat = 7;
 \end{cfa}
-Finally, there is no common type to create a type-checked instance or iterator cursor.
-Hence, there is only a weak equivalence between secondary naming and enumerations, justifying the enumeration type in a programming language.
-
-A variant (algebraic) type is often promoted as a kind of enumeration, \ie a varient type can simulate an enumeration.
-A variant type is a tagged-union, where the possible types may be heterogeneous.
-\begin{cfa}
+Finally, there is no type to create a type-checked instance or iterator cursor.
+Hence, there is only a weak equivalence between secondary naming and enumerations, justifying a seperate enumeration type in a programming language.
+
+A variant (algebraic) type is often promoted as a kind of enumeration, \ie a variant type can simulate an enumeration.
+Fundamentally, a variant type is a tagged-union, where the tag is normally opaque and the types are usually heterogeneous.
+\begin{cfa}[morekeywords={variant}]
 @variant@ Variant {
 	@int tag;@  // optional/implicit: 0 => int, 1 => double, 2 => S
@@ -103,60 +117,107 @@
 };
 \end{cfa}
-Crucially, the union implies instance storage is shared by all of the variant types.
-Hence, a variant is dynamically typed, as in a dynamic-typed programming-language, but the set of types is statically bound, similar to some aspects of dynamic gradual-typing~\cite{Gradual Typing}.
-Knowing which type is in a variant instance is crucial for correctness.
-Occasionally, it is possible to statically determine all regions where each variant type is used, so a tag and runtime checking is unnecessary;
-otherwise, a tag is required to denote the particular type in the variant and the tag checked at runtime using some form of type pattern-matching.
-
-The tag can be implicitly set by the compiler on assignment, or explicitly set by the program\-mer.
-Type pattern-matching is then used to dynamically test the tag and branch to a section of code to safely manipulate the value, \eg:
+Crucially, the union implies instance storage is shared by all the variant types, and therefore, before a variant type can be used in a statically-typed expression, it must be dynamically discriminated to its current contained type.
+Hence, knowing which type is in a variant instance is crucial for correctness.
+Occasionally, it is possible to statically determine all regions where each variant type is used, so a tag and runtime checking is unnecessary.
+Otherwise, a tag is required to denote the particular type in the variant, and the tag is discriminated at runtime using some form of type pattern-matching, after which the value can be used in a statically-typed expression.
+
+A less frequent variant case is multiple variants with the same type, which normally requires explicit naming of the tag to disambiguate among the common types.
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
+\begin{cfa}[morekeywords={variant}]
+variant VariantCT {
+	case @car@: int i;  // explicitly typed
+	case @boat@: int i;
+	case @bridge@: int i;
+};
+\end{cfa}
+&
+\begin{cfa}[morekeywords={variant}]
+variant VariantCU {
+	case @car@: ;  // empty or unit type
+	case @boat@: ;
+	case @bridge@: ;
+};
+\end{cfa}
+\end{tabular}
+\end{cquote}
+Here, the explicit tag name is used to give different meaning to the values in the common @int@ type, \eg the value 3 has different interpretations depending on the tag name.
+It is even possible to remove the type or use the empty @unit@ type (@struct unit {}@).
+It is this tag naming that is used to simulate an enumeration.
+
+Normally, the variant tag is implicitly set by the compiler based on type, but with common types, a tag name is required to resolve type ambiguity.
+\begin{cfa}
+Variant v = 3;							$\C{// implicitly set tag to 0 based on type of 3}$
+VariantCT ve = boats.3;					$\C{// explicitly set tag to 1 using tag name}$
+\end{cfa}
+Type pattern-matching is then used to dynamically test the tag and branch to a section of statically-typed code to safely manipulate the value, \eg:
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \begin{cfa}[morekeywords={match}]
-Variant v = 3;  // implicitly set tag to 0
-@match@( v ) {    // know the type or test the tag
-	case int { /* only access i field in v */ }
-	case double { /* only access d field in v */ }
-	case S { /* only access s field in v */ }
+@match@( v ) { // know type implicitly or test tag
+	case int { /* only access i field */ }
+	case double { /* only access d field */ }
+	case S { /* only access s field */ }
 }
 \end{cfa}
-For safety, either all variant types must be listed or a @default@ case must exist with no field accesses.
-
-To simulate an enumeration with a variant, the tag is \emph{re-purposed} for either ordering or value and the variant types are omitted.
-\begin{cfa}
-variant Weekday {
-	int tag; // implicit 0 => Mon, ..., 6 => Sun
-	@case Mon;@ // no type
+&
+\begin{cfa}[morekeywords={match}]
+@match@( ve ) {
+	case car: int { /* car interpretation */ }
+	case boat: int { /* boat interpretation */ }
+	case bridge: int { /* bridge interpretation */ }
+}
+\end{cfa}
+\end{tabular}
+\end{cquote}
+For safety, some languages require all variant types to be listed or a @default@ case with no field accesses.
+
+To further strengthen the simulate for an enumeration with different values, each variant type can be a @const@ type or the tag becomes non-opaque, possibly taking advantage of the opaque auto-numbering.
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
+\begin{cfa}
+variant Week {
+	case Mon: const int = 0;
 	...
-	@case Sun;@
-};
-\end{cfa}
-The type system ensures tag setting and testing are correctly done.
-However, the enumeration operations are limited to the available tag operations, \eg pattern matching.
-\begin{cfa}
-Week week = Mon;
-if ( @dynamic_cast(Mon)@week ) ... // test tag == Mon
-\end{cfa}
+	case Sat: const int = 5;
+	case Sun: const int = 10;
+};
+\end{cfa}
+&
+\begin{cfa}
+variant Week {
+	case Mon: ;  // tag auto-numbering
+	...
+	case Sat: ;
+	case @Sun = 10@: ; // directly set tag value
+};
+\end{cfa}
+\end{tabular}
+\end{cquote}
+Directly setting the tag implies restrictions, like unique values.
+In both cases, instances of @Week@ are @const@ (immutable).
+However, usage between these two types becomes complex.
+\begin{cfa}
+Week day = Week.Mon;  // sets value or tag depending on type
+if ( day == Week.Mon )   // dereference value or tag ?
+\end{cfa}
+Here, the dereference of @day@ should return the value of the type stored in the variant, never the tag.
+If it does return the tag, some special meaning must be given to the empty/unit type, especially if a variant contains both regular and unit types.
+
+
+In general, the enumeration simulation and the variant extensions to support it, are deviating from the normal use of a variant (union) type.
+As well, the enumeration operations are limited to the available tag operations, \eg pattern matching.
 While enumerating among tag names is possible:
 \begin{cfa}[morekeywords={in}]
-for ( cursor in Mon, Wed, Fri, Sun ) ...
-\end{cfa}
-ordering for iteration would require a \emph{magic} extension, such as a special @enum@ variant, because it has no meaning for a regular variant, \ie @int@ < @double@.
-
-However, if a special @enum@ variant allows the tags to be heterogeneously typed, ordering must fall back on case positioning, as many types have incomparable values.
-Iterating using tag ordering and heterogeneous types, also requires pattern matching.
-\begin{cfa}[morekeywords={match}]
-for ( cursor = Mon; cursor <= Fri; cursor = succ( cursor) ) {
-	match( cursor ) {
-		case Mon { /* access special type for Mon */ }
-		...
-		case Fri { /* access special type for Fri */ }
-		default
-	}
-}
-\end{cfa}
-If the variant type is changed by adding/removing types or the loop range changes, the pattern matching must be adjusted.
-As well, if the start/stop values are dynamic, it may be impossible to statically determine if all variant types are listed. 
-
-Re-purposing the notion of enumerating into variant types is ill formed and confusing.
-Hence, there is only a weak equivalence between an enumeration and variant type, justifying the enumeration type in a programming language.
+for ( cursor in Week.Mon, Week.Wed, Week.Fri, Week.Sun ) ...
+\end{cfa}
+what is the type of @cursor@?
+If it the tag type (@int@), how is this value used?
+If it is the variant type, where is the instance variable, which only contains one value.
+Hence, either enumerating with a variant enumeration is disallowed or some unusual typing rule must be invented to make it work but only in restricted contexts.
+
+While functional programming systems regularly re-purposing variant types into enumeration types, this process seems contrived and confusing.
+A variant tag is not an enumeration, it is a discriminant among a restricted set of types stored in a storage block.
+Hence, there is only a weak equivalence between an enumeration and variant type, justifying a seperate enumeration type in a programming language.
 
 
Index: doc/theses/jiada_liang_MMath/relatedwork.tex
===================================================================
--- doc/theses/jiada_liang_MMath/relatedwork.tex	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/theses/jiada_liang_MMath/relatedwork.tex	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -53,29 +53,16 @@
 \lstnewenvironment{ada}[1][]{\lstset{language=[2005]Ada,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},literate={'}{\ttfamily'\!}1}\lstset{#1}}{}
 
-An Ada enumeration type is an ordered list of constants, called \Newterm{literals} (enumerators).
+An Ada enumeration type is a set of ordered unscoped identifiers (enumerators) bound to \emph{unique} \Newterm{literals}.\footnote{%
+Ada is \emph{case-insensitive} so identifiers may appear in multiple forms and still be the same, \eg \lstinline{Mon}, \lstinline{moN}, and \lstinline{MON} (a questionable design decision).}
 \begin{ada}
-type RGB is ( Red, Green, Blue ); -- 3 literals (enumerators)
+type Week is ( Mon, Tue, Wed, Thu, Fri, Sat, Sun ); -- literals (enumerators)
 \end{ada}
 Object initialization and assignment are restricted to the enumerators of this type.
-Enumerators without an explicitly designated constant value are auto-initialized: from left to right, starting at zero or the next explicitly initialized constant, incrementing by 1.
-To explicitly set enumerator values, \emph{all} enumerators must be set in \emph{ascending} order, \ie there is no auto-initialization.
+While Ada enumerators are unscoped, like C, Ada enumerators are overloadable.
 \begin{ada}
-type RGB is ( Red, Green, Blue );
-@for RGB use ( Red => 10, Green => 20, Blue => 30 );@ -- ascending order
-\end{ada}
-Hence, the position, value, label tuples are:
-\begin{ada}
-(0, 10, RED)  (1, 20, GREEN)  (2, 30, BLUE) 
-\end{ada}
-Note, Ada is case-\emph{insensitive} so names may appear in multiple forms and still be the same, \eg @Red@ and @RED@ (a questionable design decision).
-
-Like C, Ada enumerators are unscoped, \ie enumerators declared inside of an enum are visible (projected) into the enclosing scope.
-The enumeration operators are the ordering operators, @=@, @<@, @<=@, @=@, @/=@, @>=@, @>@, where the ordering relationship is given implicitly by the sequence of enumerators, which is always ascending.
-
-Ada enumerators are overloadable.
-\begin{ada}
+type RGB is ( @Red@, @Green@, Blue );
 type Traffic_Light is ( @Red@, Yellow, @Green@ );
 \end{ada}
-Like \CFA, Ada uses an advanced type-resolution algorithm, including the left-hand side of assignment, to disambiguate among overloaded names.
+Like \CFA, Ada uses an advanced type-resolution algorithm, including the left-hand side of assignment, to disambiguate among overloaded identifiers.
 \VRef[Figure]{f:AdaEnumeration} shows how ambiguity is handled using a cast, \ie \lstinline[language=ada]{RGB'(Red)}.
 
@@ -102,5 +89,13 @@
 \end{figure}
 
-Ada provides an alias mechanism, \lstinline[language=ada]{renames}, for aliasing types, which is useful to shorten package names.
+Enumerators without initialization are auto-initialized from left to right, starting at zero, incrementing by 1.
+Enumerators with initialization must set \emph{all} enumerators in \emph{ascending} order, \ie there is no auto-initialization.
+\begin{ada}
+type Week is ( Mon, Tue, Wed, Thu, Fri, Sat, Sun );
+for Week use ( Mon => 0, Tue => 1, Wed => 2, Thu => @10@, Fri => 11, Sat => 14, Sun => 15 );
+\end{ada}
+The enumeration operators are the equality and relational operators, @=@, @/=@, @<@, @<=@, @=@, @/=@, @>=@, @>@, where the ordering relationship is given implicitly by the sequence of acsending enumerators.
+
+Ada provides an alias mechanism, \lstinline[language=ada]{renames}, for aliasing types, which is useful to shorten package identifiers.
 \begin{ada}
 OtherRed : RGB renames Red;
@@ -113,5 +108,4 @@
 There are three pairs of inverse enumeration pseudo-functions (attributes): @'Pos@ and @'Val@, @'Enum_Rep@ and @'Enum_Val@, and @'Image@ and @'Value@,
 \begin{cquote}
-\lstDeleteShortInline@
 \setlength{\tabcolsep}{15pt}
 \begin{tabular}{@{}ll@{}}
@@ -128,5 +122,4 @@
 \end{ada}
 \end{tabular}
-\lstMakeShortInline@
 \end{cquote}
 These attributes are important for IO.
@@ -138,5 +131,5 @@
 \end{ada}
 which is syntactic sugar for the label and not character literals from the predefined type @Character@.
-The purpose is strictly readability using character literals rather than names.
+The purpose is strictly readability using character literals rather than identifiers.
 \begin{ada}
 Op : Operator := '+';
@@ -171,5 +164,4 @@
 An enumeration type can be used in the Ada \lstinline[language=ada]{case} (all enumerators must appear or a default) or iterating constructs.
 \begin{cquote}
-\lstDeleteShortInline@
 \setlength{\tabcolsep}{15pt}
 \begin{tabular}{@{}ll@{}}
@@ -211,5 +203,4 @@
 \end{ada}
 \end{tabular}
-\lstMakeShortInline@
 \end{cquote}
 
@@ -229,5 +220,5 @@
 \CC has the equivalent of Pascal typed @const@ declarations \see{\VRef{s:Pascal}}, with static and dynamic initialization.
 \begin{c++}
-const auto one = 0 + 1;					$\C{// static intialization}$
+const auto one = 0 + 1;					$\C{// static initialization}$
 const auto NULL = nullptr;
 const auto PI = 3.14159;
@@ -237,5 +228,5 @@
 				Sat = Fri + 1, Sun = Sat + 1;
 int sa[Sun];
-const auto r = random();				$\C{// dynamic intialization}$
+const auto r = random();				$\C{// dynamic initialization}$
 int da[r];								$\C{// VLA}$
 \end{c++}
@@ -362,5 +353,4 @@
 \begin{figure}
 \centering
-\lstDeleteShortInline@
 \begin{tabular}{@{}l|l@{}}
 \multicolumn{1}{@{}c|}{non-object oriented} & \multicolumn{1}{c@{}}{object oriented} \\
@@ -414,5 +404,4 @@
 \end{csharp}
 \end{tabular}
-\lstMakeShortInline@
 \caption{\Csharp: Free Routine Versus Class Enumeration}
 \label{CsharpFreeVersusClass}
@@ -429,5 +418,5 @@
 const ( S = 0; T; USA = "USA"; U; V = 3.1; W ) $\C{// type change, implicit/explicit: 0 0 USA USA 3.1 3.1}$
 \end{Go}
-Constant names are unscoped and must be unique (no overloading).
+Constant identifiers are unscoped and must be unique (no overloading).
 The first enumerator \emph{must} be explicitly initialized;
 subsequent enumerators can be implicitly or explicitly initialized.
@@ -459,5 +448,4 @@
 Basic switch and looping are possible.
 \begin{cquote}
-\lstDeleteShortInline@
 \setlength{\tabcolsep}{15pt}
 \begin{tabular}{@{}ll@{}}
@@ -482,5 +470,4 @@
 \end{Go}
 \end{tabular}
-\lstMakeShortInline@
 \end{cquote}
 However, the loop prints the values from 0 to 13 because there is no actual enumeration.
@@ -513,5 +500,4 @@
 \begin{figure}
 \centering
-\lstDeleteShortInline@
 \begin{tabular}{@{}l|l@{}}
 \multicolumn{1}{@{}c|}{non-object oriented} & \multicolumn{1}{c@{}}{object oriented} \\
@@ -553,5 +539,4 @@
 \end{Java}
 \end{tabular}
-\lstMakeShortInline@
 \caption{Java: Free Routine Versus Class Enumeration}
 \label{f:JavaFreeVersusClass}
@@ -607,4 +592,5 @@
 \section{Rust}
 \lstnewenvironment{rust}[1][]{\lstset{language=Rust,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
+% https://doc.rust-lang.org/reference/items/enumerations.html
 
 Rust provides a scoped enumeration based on variant types.
@@ -1010,73 +996,65 @@
 
 
-\section{Python}
+\section{Python 3.13}
 \lstnewenvironment{python}[1][]{\lstset{language=Python,escapechar=\$,moredelim=**[is][\color{red}]{@}{@},}\lstset{#1}}{}
-
-A Python enumeration is a set of symbolic names bound to \emph{unique} values.
-They are similar to global variables, but offer a more useful @repr()@, grouping, type-safety, and additional features.
-Enumerations inherits from the @Enum@ class, \eg:
-\begin{python}
-class Weekday(@Enum@): Mon = 1; Tue = 2; Wed = 3; Thu = 4; Fri = 5; Sat = 6; Sun = 7
-class RGB(@Enum@): Red = 1; Green = 2; Blue = 3
-\end{python}
-
-Depending on the nature of the enum a member's value may or may not be important, but either way that value can be used to get the corresponding member:
-\begin{python}
-print( repr( Weekday( 3 ) ) )
-<Weekday.Wed: 3>
-\end{python}
-As you can see, the @repr()@ of a member shows the enum name, the member name, and the value.
-The @str()@ of a member shows only the enum name and member name:
-\begin{python}
-print( str( Weekday.Thu ), Weekday.Thu )
-Weekday.Thu Weekday.Thu
-\end{python}
-The type of an enumeration member is the enum it belongs to:
-\begin{python}
-print( type( Weekday.Thu ) )
-<enum 'Weekday'>
-print( isinstance(Weekday.Fri, Weekday) )
-True
-\end{python}
-Enum members have an attribute that contains just their name:
-\begin{python}
-print(Weekday.TUESDAY.name)
-TUESDAY
-\end{python}
-Likewise, they have an attribute for their value:
-\begin{python}
-Weekday.WEDNESDAY.value
-3
-\end{python}
-
-Unlike many languages that treat enumerations solely as name/value pairs, Python @Enum@s can have behavior added.
-For example, @datetime.date@ has two methods for returning the weekday: @weekday()@ and @isoweekday()@.
-The difference is that one of them counts from 0-6 and the other from 1-7.
-Rather than keep track of that ourselves we can add a method to the @Weekday@ enum to extract the day from the date instance and return the matching enum member:
-\begin{python}
-class Weekday(Enum): Mon = 1; Tue = 2; Wed = 3; Thu = 10; Fri = 15; Sat = 16; Sun = 17
-$@$classmethod
-def from_date(cls, date):
-	return cls(date.isoweekday())
-\end{python}
-Now we can find out what today is! Observe:
-\begin{python}
->>> from datetime import date
->>> Weekday.from_date(date.today())     
-<Weekday.TUESDAY: 2>
-\end{python}
-Of course, if you're reading this on some other day, you'll see that day instead.
-
-This Weekday enum is great if our variable only needs one day, but what if we need several? Maybe we're writing a function to plot chores during a week, and don't want to use a @list@ -- we could use a different type of @Enum@:
-\begin{python}
-from enum import Flag
-class WeekdayF(@Flag@): Mon = @1@; Tue = @2@; Wed = @4@; Thu = @8@; Fri = @16@; Sat = @32@; Sun = @64@
-\end{python}
-We've changed two things: we're inherited from @Flag@, and the values are all powers of 2.
+% https://docs.python.org/3/howto/enum.html
+
+Python is a dynamically-typed reflexive programming language with multiple versions, and hence, it is possible to extend existing or build new language features within the language.
+As a result, discussing Python enumerations is a moving target, because if a features does not exist, if can often be created with varying levels of complexity.
+Nevertheless, an attempt has been made to discuss core enumeration features that come with Python 3.13.
+
+A Python enumeration type is a set of ordered scoped identifiers (enumerators) bound to \emph{unique} values.
+An enumeration is not a basic type;
+it is a @class@ inheriting from the @Enum@ class, where the enumerators must be explicitly initialized, \eg:
+\begin{python}
+class Week(@Enum@): Mon = 1; Tue = 2; Wed = 3; Thu = 4; Fri = 5; Sat = 6; Sun = 7
+\end{python}
+and/or explicitly auto initialized, \eg:
+\begin{python}
+class Week(Enum): Mon = 1; Tue = 2; Wed = 3; Thu = 10; Fri = @auto()@; Sat = 4; Sun = @auto()@
+\end{python}
+where @auto@ increments by 1 from the previous enumerator value.
+Object initialization and assignment are restricted to the enumerators of this type.
+An enumerator initialized with same value is an alias and invisible at the enumeration level, \ie the alias it substituted for its aliasee.
+\begin{python}
+class Week(Enum): Mon = 1; Tue = 2; Wed = 3; Thu = 10; Fri = @10@; Sat = @10@; Sun = @10@
+\end{python}
+Here, the enumeration has only 4 enumerators and 3 aliases.
+An alias is only visible by dropping down to the @class@ level and asking for class members.
+@Enum@ only supports equality comparison between enumerator values;
+the extended class @OrderedEnum@ adds relational operators @<@, @<=@, @>@, and @>=@.
+
+There are bidirectional enumeration pseudo-functions for label and value, but there is no concept of access using ordering (position).
+\begin{cquote}
+\setlength{\tabcolsep}{15pt}
+\begin{tabular}{@{}ll@{}}
+\begin{python}
+Week.Thu.value == 10;
+Week.Thu.name == 'Thu';
+\end{python}
+&
+\begin{python}
+Week( 10 ) == Thu
+Week['Thu'].value = 10
+\end{python}
+\end{tabular}
+\end{cquote}
+
+As an enumeration is a \lstinline[language=python]{class}, its own methods.
+\begin{python}
+class Week(Enum):
+	Mon = 1; Tue = 2; Wed = 3; Thu = 4; Fri = 5; Sat = 6; Sun = 7
+	$\\@$classmethod
+	def today(cls, date):
+		return cls(date.isoweekday())
+print( "today:", Week.today(date.today()))
+today: Week.Mon
+\end{python}
+The method @today@ retrieves the day of the week and uses it as an index to print out the corresponding label of @Week@.
 
 @Flag@ allows combining several members into a single variable:
 \begin{python}
-print( repr(WeekdayF.Sat | WeekdayF.Sun) )
-<WeekdayF.Sun|Sat: 96>
+print( repr(WeekF.Sat | WeekF.Sun) )
+<WeekF.Sun|Sat: 96>
 \end{python}
 You can even iterate over a @Flag@ variable:
@@ -1084,13 +1062,13 @@
 for day in weekend:
 	print(day)
-Weekday.SATURDAY
-Weekday.SUNDAY
+WeekF.Sat
+WeekF.Sun
 \end{python}
 Okay, let's get some chores set up:
 \begin{python}
 >>> chores_for_ethan = {
-...    'feed the cat': Weekday.MONDAY | Weekday.WEDNESDAY | Weekday.FRIDAY,
-...    'do the dishes': Weekday.TUESDAY | Weekday.THURSDAY,
-...    'answer SO questions': Weekday.SATURDAY,
+...    'feed the cat': Week.MONDAY | Week.WEDNESDAY | Week.FRIDAY,
+...    'do the dishes': Week.TUESDAY | Week.THURSDAY,
+...    'answer SO questions': Week.SATURDAY,
 ...    }
 \end{python}
@@ -1101,19 +1079,14 @@
 ...        if day in days:
 ...            print(chore)
->>> show_chores(chores_for_ethan, Weekday.SATURDAY)
+>>> show_chores(chores_for_ethan, Week.SATURDAY)
 answer SO questions
 \end{python}
-In cases where the actual values of the members do not matter, you can save yourself some work and use @auto()@ for the values:
-\begin{python}
->>> from enum import auto
->>> class Weekday(Flag):
-...    MONDAY = auto()
-...    TUESDAY = auto()
-...    WEDNESDAY = auto()
-...    THURSDAY = auto()
-...    FRIDAY = auto()
-...    SATURDAY = auto()
-...    SUNDAY = auto()
-...    WEEKEND = SATURDAY | SUNDAY
+Auto incrmenet for @Flag@ is by powers of 2.
+\begin{python}
+class WeekF(Flag): Mon = auto(); Tue = auto(); Wed = auto(); Thu = auto(); Fri = auto();  \
+							Sat = auto(); Sun = auto(); Weekend = Sat | Sun
+for d in WeekF:
+	print( f"{d.name}: {d.value}", end=" ")
+Mon: 1 Tue: 2 Wed: 4 Thu: 8 Fri: 16 Sat: 32 Sun: 64 WeekA.Weekend
 \end{python}
 
@@ -1123,44 +1096,19 @@
 @Enum@ allows such access:
 \begin{python}
->>> Color(1)
-<Color.RED: 1>
->>> Color(3)
-<Color.BLUE: 3>
+print(RGB(1), RGB(3), )
+RGB.RED RGB.GREEN
 \end{python}
 If you want to access enum members by name, use item access:
 \begin{python}
-Color['RED']
-<Color.RED: 1>
-
-Color['GREEN']
-<Color.GREEN: 2>
+print( RGBa['RED'], RGBa['GREEN'] )
+RGB.RED RGB.GREEN
 \end{python}
 If you have an enum member and need its name or value:
 \begin{python}
->>> member = Color.RED
->>> member.name
-'RED'
->>> member.value
-1
-\end{python}
-
-\subsection{Duplicating enum members and values}
-
-An enum member can have other names associated with it.
-Given two entries @A@ and @B@ with the same value (and @A@ defined first), @B@ is an alias for the member @A@.
-By-value lookup of the value of @A@ will return the member @A@.
-By-name lookup of @A@ will return the member @A@.
-By-name lookup of @B@ will also return the member @A@:
-\begin{python}
-class Shape(Enum): SQUARE = 2; DIAMOND = 1; CIRCLE = 3; ALIAS_FOR_SQUARE = 2
->>> Shape.SQUARE
-<Shape.SQUARE: 2>
->>> Shape.ALIAS_FOR_SQUARE
-<Shape.SQUARE: 2>
->>> Shape(2)
-<Shape.SQUARE: 2>
-\end{python}
-
-Note: Attempting to create a member with the same name as an already defined attribute (another member, a method, etc.) or attempting to create an attribute with the same name as a member is not allowed.
+member = RGBa.RED
+print( f"{member.name} {member.value}" )
+RED 1
+\end{python}
+
 
 \subsection{Ensuring unique enumeration values}
@@ -1207,9 +1155,9 @@
 >>> list(Shape)
 [<Shape.SQUARE: 2>, <Shape.DIAMOND: 1>, <Shape.CIRCLE: 3>]
->>> list(Weekday)
-[<Weekday.MONDAY: 1>, <Weekday.TUESDAY: 2>, <Weekday.WEDNESDAY: 4>, <Weekday.THURSDAY: 8>,
-<Weekday.FRIDAY: 16>, <Weekday.SATURDAY: 32>, <Weekday.SUNDAY: 64>]
-\end{python}
-Note that the aliases @Shape.ALIAS_FOR_SQUARE@ and @Weekday.WEEKEND@ aren't shown.
+>>> list(Week)
+[<Week.MONDAY: 1>, <Week.TUESDAY: 2>, <Week.WEDNESDAY: 4>, <Week.THURSDAY: 8>,
+<Week.FRIDAY: 16>, <Week.SATURDAY: 32>, <Week.SUNDAY: 64>]
+\end{python}
+Note that the aliases @Shape.ALIAS_FOR_SQUARE@ and @Week.WEEKEND@ aren't shown.
 
 The special attribute @__members__@ is a read-only ordered mapping of names to members.
@@ -2218,9 +2166,8 @@
 
 OCaml provides a variant (union) type, where multiple heterogeneously-typed objects share the same storage.
-The simplest form of the variant type is a list of nullary datatype constructors, which is like an unscoped, pure enumeration.
-
-(I think the value of a ocaml variants are types not object, so I am not sure about this line)
+The simplest form of the variant type is a list of nullary datatype constructors, which is like an unscoped, opaque enumeration.
+
 OCaml provides a variant (union) type, which is an aggregation of heterogeneous types.
-A basic variant is a list of nullary datatype constructors, which is like an unscoped, pure enumeration. 
+A basic variant is a list of nullary datatype constructors, which is like an unscoped, opaque enumeration.
 \begin{ocaml}
 type weekday = Mon | Tue | Wed | Thu | Fri | Sat | Sun
@@ -2246,5 +2193,5 @@
 type colour = Red | Green of @string@ | Blue of @int * float@
 \end{ocaml}
-A variant with parameter is stored in a memory block, prefixed by an int tag and has its parameters stores as words in the block. 
+A variant with parameter is stored in a memory block, prefixed by an int tag and has its parameters stores as words in the block.
 @colour@ is a summation of a nullary type, a unary product type of @string@, and a cross product of @int@ and @float@.
 (Mathematically, a @Blue@ value is a Cartesian product of the types @int@ type and @float@.)
@@ -2259,5 +2206,4 @@
 @Red, abc, 1 1.5@
 \end{ocaml}
-
 
 A variant type can have a recursive definition.
@@ -2280,5 +2226,5 @@
 
 In summary, an OCaml variant is a singleton value rather than a set of possibly ordered values, and hence, has no notion of enumerabilty.
-Therefore it is not an enumeration, except for the simple pure (nullary) case.
+Therefore it is not an enumeration, except for the simple opaque (nullary) case.
 
 \begin{comment}
@@ -2466,4 +2412,32 @@
 With valediction,
   - Gregor Richards
+
+
+Date: Tue, 16 Apr 2024 11:04:51 -0400
+Subject: Re: C unnamed enumeration
+To: "Peter A. Buhr" <pabuhr@uwaterloo.ca>
+CC: <ajbeach@uwaterloo.ca>, <j82liang@uwaterloo.ca>, <mlbrooks@uwaterloo.ca>,
+        <f37yu@uwaterloo.ca>
+From: Gregor Richards <gregor.richards@uwaterloo.ca>
+
+On 4/16/24 09:55, Peter A. Buhr wrote:
+> So what is a variant? Is it a set of tag names, which might be a union or is it
+> a union, which might have tag names?
+
+Your tagless variant bears no resemblance to variants in any functional
+programming language. A variant is a tag AND a union. You might not need to put
+anything in the union, in which case it's a pointless union, but the named tag
+is absolutely mandatory. That's the thing that varies.
+
+I was unaware of std::variant. As far as functional languages are concerned,
+std::variant IS NOT A VARIANT. Perhaps it would be best to use the term ADT for
+the functional language concept, because that term has no other meanings.
+
+An ADT cannot not have a named tag. That's meaningless. The tag is the data
+constructor, which is the thing you actually define when you define an ADT. It
+is strictly the union that's optional.
+
+With valediction,
+  - Gregor Richards
 \end{comment}
 
@@ -2487,5 +2461,5 @@
 \hline
 \hline
-pure			&		&		&		&		&		&		&		&	  	&		&		&		&		& \CM	\\
+opaque			&		&		&		&		&		&		&		&	  	&		&		&		&		& \CM	\\
 \hline
 typed			&		&		&		&		&		&		&		&	  	&		&		& @int@	& integral	& @T@	\\
Index: doc/theses/jiada_liang_MMath/uw-ethesis.bib
===================================================================
--- doc/theses/jiada_liang_MMath/uw-ethesis.bib	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/theses/jiada_liang_MMath/uw-ethesis.bib	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -2,2 +2,12 @@
 % 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,
+}
Index: doc/uC++toCFA/Makefile
===================================================================
--- doc/uC++toCFA/Makefile	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/uC++toCFA/Makefile	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -56,6 +56,6 @@
 	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
Index: doc/uC++toCFA/uC++toCFA.tex
===================================================================
--- doc/uC++toCFA/uC++toCFA.tex	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/uC++toCFA/uC++toCFA.tex	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -11,6 +11,6 @@
 %% 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
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -141,19 +141,18 @@
 \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;
@@ -201,7 +200,6 @@
 
 \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@>
@@ -226,5 +224,5 @@
 
 \begin{cquote}
-\begin{tabular}{l|l}
+\begin{tabular}{@{}l|l@{}}
 \begin{uC++}
 for ( @;;@ ) { ... }  /  while ( @true@ ) { ... }
@@ -280,5 +278,5 @@
 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++}
 
@@ -321,5 +319,5 @@
 
 \begin{cquote}
-\begin{tabular}{l|ll}
+\begin{tabular}{@{}l|ll@{}}
 \begin{uC++}
 
@@ -360,5 +358,5 @@
 
 \begin{cquote}
-\begin{tabular}{l|l}
+\begin{tabular}{@{}l|l@{}}
 \begin{uC++}
 struct S {
@@ -383,6 +381,6 @@
 
 \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";
@@ -425,5 +423,5 @@
 
 \begin{cquote}
-\begin{tabular}{l|l}
+\begin{tabular}{@{}l|l@{}}
 \begin{uC++}
 struct S {
@@ -456,5 +454,5 @@
 
 \begin{cquote}
-\begin{tabular}{l|l}
+\begin{tabular}{@{}l|l@{}}
 \begin{uC++}
 
@@ -493,5 +491,5 @@
 
 \begin{cquote}
-\begin{tabular}{l|ll}
+\begin{tabular}{@{}l|ll@{}}
 \begin{uC++}
 
@@ -532,5 +530,5 @@
 
 \begin{cquote}
-\begin{tabular}{l|ll}
+\begin{tabular}{@{}l|ll@{}}
 \begin{uC++}
 
@@ -567,5 +565,5 @@
 
 \begin{cquote}
-\begin{tabular}{l|ll}
+\begin{tabular}{@{}l|ll@{}}
 \begin{uC++}
 
@@ -604,5 +602,5 @@
 
 \begin{cquote}
-\begin{tabular}{l|ll}
+\begin{tabular}{@{}l|ll@{}}
 \begin{uC++}
 
Index: doc/user/Makefile
===================================================================
--- doc/user/Makefile	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/user/Makefile	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -60,6 +60,6 @@
 	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
@@ -73,5 +73,5 @@
 	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
Index: doc/user/user.tex
===================================================================
--- doc/user/user.tex	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ doc/user/user.tex	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -11,6 +11,6 @@
 %% 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 : Thu Apr 18 21:53:45 2024
+%% Update Count     : 6502
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -130,5 +130,5 @@
 \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.
@@ -312,5 +312,5 @@
 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();
@@ -1023,47 +1023,47 @@
 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}
 &
@@ -2960,4 +2960,6 @@
 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.
+
+{\color{red}
 As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity:
 \begin{cfa}
@@ -2967,5 +2969,5 @@
 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.
+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.}
 
 C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
@@ -3055,4 +3057,157 @@
 static [ int ] g ( int );
 \end{cfa}
+
+
+\subsection{Postfix Function}
+\label{s:PostfixFunction}
+
+\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}
+0`h;
+3.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;
+3`p;
+i`p;
+(i + 3)`p;
+\end{cfa}
+\end{tabular}
+\end{cquote}
+
+\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.
 
 
@@ -3809,8 +3964,8 @@
 \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);
 
@@ -4925,8 +5080,8 @@
 	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;
@@ -7775,5 +7930,5 @@
 \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) );
@@ -7988,151 +8143,301 @@
 \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.
+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}
+
+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
+Extend 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 = alloc();						§\C{// \CFA type-safe call of \CFA alloc}§
+struct __attribute__(( aligned(128) )) spinlock { ... };
+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
+Introduce 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
+Provide resizing without data copying, which is useful to repurpose an existing block of storage for another purpose, rather than freeing the old storage and performing a new allocation.
+The resize might be able to take advantage of unused storage after the data to preventing the free/reallocation step altogether.
+
+\item
+Provide ©free©/©delete© functions that delete a variable number of pointers.
+\begin{cfa}
+int * ip = malloc(), * jp = malloc(), * kp = malloc(); 
+double * xp = malloc(), * yp = malloc(), * zp = malloc(); 
+free( ®ip, jp, kp, xp, yp, zp® );
+\end{cfa}
+
+\item
+Support constructors for initialization of allocated storage (like \CC) and destructors for deallocation.
+\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}§
+
+3
+5 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
+\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 ©T * alloc( ... )© and ©T * alloc( size_t dim, ... )© are overloaded with a variable number of specific allocation properties, or an integer dimension parameter followed by a variable number of specific allocation properties.
+These allocation properties can be passed as named arguments when calling the \lstinline{alloc} routine.
+A call without parameters returns an uninitialized dynamically allocated object of type ©T© (©malloc©).
+A call with only the dimension (dim) parameter returns an uninitialized dynamically allocated array of objects with type ©T© (©aalloc©).
+The variable number of arguments consist of allocation properties, which can be combined to produce different kinds of allocations.
+The properties ©resize© and ©realloc© are associated with the allocation variable indicating how the existing allocation is modified, without or with data copying.
+Function ©alloc© is used extensively in the \CFA runtime.
+
+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:
+\begin{cfa}
+int * i0 = alloc( ®4096`align® );  sout | i0 | nl;
+int * i1 = alloc( 3, ®4096`align® );  sout | i1; for (i; 3 ) sout | &i1[i] | nonl; sout | nl;
+
+0x555555572000
+0x555555574000 0x555555574000 0x555555574004 0x555555574008
+\end{cfa}
+returns a dynamic object and object array aligned on a 4096-byte boundary.
+
+\item
+©S_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 0
+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
+\end{cfa}
+\begin{lstlisting}[numbers=left]
+0
+5
+0xfefefefe
+5 5 5 5 5
+0xdeadbeef 0xdeadbeef 0xdeadbeef 0xdeadbeef 0xdeadbeef
+5 5 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 * i = alloc( ®5`fill® );  sout | i | *i;
+i = alloc( ®i`resize®, ®256`align®, ®7`fill® );  sout | i | *i;
+double * d = alloc( ®i`resize®, ®4096`align®, ®13.5`fill® );  sout | d | *d;
+\end{cfa}
+\begin{lstlisting}[numbers=left]
+0x55555556d5c0 5
+0x555555570000 7
+0x555555571000 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® );  for ( i; 5 ) sout | ia[i] | nonl; sout | nl;
+ia = alloc( 10, ®ia`resize®, ®7`fill® ); for ( i; 10 ) sout | ia[i] | nonl; sout | nl;
+sout | ia; ia = alloc( 5, ®ia`resize®, ®512`align®, ®13`fill® ); sout | ia; for ( i; 5 ) sout | ia[i] | nonl; sout | nl;;
+ia = alloc( 3, ®ia`resize®, ®4096`align®, ®2`fill® );  sout | ia; for ( i; 3 ) sout | &ia[i] | ia[i] | nonl; sout | nl;
+\end{cfa}
+\begin{lstlisting}[numbers=left]
+5 5 5 5 5
+7 7 7 7 7 7 7 7 7 7
+0x55555556d560 0x555555571a00 13 13 13 13 13
+0x555555572000 0x555555572000 2 0x555555572004 2 0x555555572008 2
+\end{lstlisting}
+Examples 2 to 4 change the array size, alignment and fill for the initial storage of ©ia©.
+
+\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 * i = alloc( ®5`fill® );  sout | i | *i;
+i = alloc( ®i`realloc®, ®256`align® );  sout | i | *i;
+i = alloc( ®i`realloc®, ®4096`align®, ®13`fill® );  sout | i | *i;
+\end{cfa}
+\begin{lstlisting}[numbers=left]
+0x55555556d5c0 5
+0x555555570000 5
+0x555555571000 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 extra space is added.
+
+\begin{cfa}[numbers=left]
+int * ia = alloc( 5, ®5`fill® );  for ( i; 5 ) sout | ia[i]; sout | nl;
+ia = alloc( 10, ®ia`realloc®, ®7`fill® ); for ( i; 10 ) sout | ia[i]; sout | nl;
+sout | ia; ia = alloc( 1, ®ia`realloc®, ®512`align®, ®13`fill® ); sout | ia; for ( i; 1 ) sout | ia[i]; sout | nl;;
+ia = alloc( 3, ®ia`realloc®, ®4096`align®, ®2`fill® );  sout | ia; for ( i; 3 ) sout | &ia[i] | ia[i]; sout | nl;
+\end{cfa}
+\begin{lstlisting}[numbers=left]
+5 5 5 5 5
+5 5 5 5 5 7 7 7 7 7
+0x55555556c560 0x555555570a00 5
+0x555555571000 0x555555571000 5 0x555555571004 2 0x555555571008 2
+\end{lstlisting}
+Examples 2 to 4 change the array size, alignment and fill for the initial storage of ©ia©.
+The ©13`fill© in example 3 does nothing because no extra space 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 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 * realloc( T * ptr, size_t size );§\indexc{realloc}§
+	T * reallocarray( T * ptr, size_t dim );§\indexc{reallocarray}§
+	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}§
+	T * alloc( ... );§\indexc{alloc}§					§\C{// variable, T size}§
+	T * alloc( size_t dim, ... );
+	T_align ?`align( size_t alignment );§\indexc{align}§
+	S_fill(T) ?`fill( /* various types */ );§\indexc{fill}§
+	S_resize(T) ?`resize( void * oaddr );§\indexc{resize}§
+	S_realloc(T) ?`realloc( T * a ));§\indexc{realloc}§
 
 	// §\CFA§ safe initialization/copy, i.e., implicit size specification
@@ -8146,14 +8451,20 @@
 
 // §\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 );
+forall( T &, TT ... ) void free( T * ptr, ... ); 
+
+forall( T & | sized(T), Params ... | { void ?{}( T &, Params ); } )
+T * new( Params p );§\indexc{new}§
+forall( T & | { void ^?{}( T & ); } )
+void delete( T * ptr );§\indexc{delete}§
+forall( T &, Params ... | { 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 );
+forall( T & | sized(T), Params ... | { void ?{}( T &, Params ); } )
+T * anew( size_t dim, Params p );§\indexc{anew}§
+forall( T & | sized(T) | { void ^?{}( T & ); } )
+void adelete( T arr[] );§\indexc{adelete}§
+forall( T & | sized(T) | { void ^?{}( T & ); }, Params ... | { void adelete( Params ); } )
+void adelete( T arr[], Params rest );
 \end{cfa}
 
@@ -9290,6 +9601,6 @@
 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.
@@ -9299,6 +9610,20 @@
 \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}§
@@ -9311,18 +9636,4 @@
 		®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;
 	}
 }
@@ -9419,6 +9730,6 @@
 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}
 
@@ -9440,4 +9751,22 @@
 \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 %
Index: libcfa/src/concurrency/actor.hfa
===================================================================
--- libcfa/src/concurrency/actor.hfa	(revision 02c80cdce0384f9364e0942ca9c11fff3eed9490)
+++ libcfa/src/concurrency/actor.hfa	(revision 4e08a54df11ebeb2b3059a97fa8551eb0ee0e1e1)
@@ -299,5 +299,5 @@
 
 	if ( seperate_clus ) {
-		cluster = alloc();
+		this.cluster = alloc();
 		(*cluster){};
 	} else cluster = active_cluster();
@@ -360,5 +360,5 @@
 	adelete( worker_req_queues );
 	adelete( processors );
-	if ( seperate_clus ) delete( cluster );
+	if ( seperate_clus ) delete( this.cluster );
 
 	#ifdef ACTOR_STATS // print formatted stats
