Changeset 32cab5b for doc/papers/general/Paper.tex

Timestamp:

Apr 17, 2018, 12:01:09 PM (7 years ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, with_gc

Children:

3265399

Parents:

b2fe1c9 (diff), 81bb114 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.

Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:

• doc/papers/general/Paper.tex (modified) (88 diffs)

doc/papers/general/Paper.tex

@@ -1 @@
-\documentclass{article}
-
-\usepackage{fullpage}
+\documentclass[AMA,STIX1COL]{WileyNJD-v2}
+
+\articletype{RESEARCH ARTICLE}%
+
+\received{26 April 2016}
+\revised{6 June 2016}
+\accepted{6 June 2016}
+
+\raggedbottom
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+% Latex packages used in the document.
+
 \usepackage{epic,eepic}
-\usepackage{xspace,calc,comment}
+\usepackage{xspace}
+\usepackage{comment}
 \usepackage{upquote}                                            % switch curled `'" to straight
 \usepackage{listings}                                           % format program code
-\usepackage{enumitem}
-\setlist[itemize]{topsep=3pt,itemsep=2pt,parsep=0pt}% global
-\usepackage[flushmargin]{footmisc}                      % support label/reference in footnote
-\usepackage{rotating}
-\usepackage[usenames]{color}
-\usepackage{pslatex}                                            % reduce size of san serif font
-\usepackage[plainpages=false,pdfpagelabels,pdfpagemode=UseNone,pagebackref=true,breaklinks=true,colorlinks=true,linkcolor=blue,citecolor=blue,urlcolor=blue]{hyperref}
-\urlstyle{sf}
-\usepackage{breakurl}
-
-\setlength{\textheight}{9in}
-%\oddsidemargin 0.0in
-\renewcommand{\topfraction}{0.8}                        % float must be greater than X of the page before it is forced onto its own page
-\renewcommand{\bottomfraction}{0.8}                     % float must be greater than X of the page before it is forced onto its own page
-\renewcommand{\floatpagefraction}{0.8}          % float must be greater than X of the page before it is forced onto its own page
-\renewcommand{\textfraction}{0.0}                       % the entire page maybe devoted to floats with no text on the page at all
+%\usepackage{enumitem}
+%\setlist[itemize]{topsep=3pt,itemsep=2pt,parsep=0pt}% global
+%\usepackage{rotating}
+
+\hypersetup{breaklinks=true}
+\definecolor{ForestGreen}{cmyk}{1, 0, 0.99995, 0}
+
+\usepackage[pagewise]{lineno}
+\renewcommand{\linenumberfont}{\scriptsize\sffamily}
 
 \lefthyphenmin=4                                                        % hyphen only after 4 characters
 \righthyphenmin=4
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 % Names used in the document.
@@ -64 +71 @@
 \newlength{\gcolumnposn}                                        % temporary hack because lstlisting does not handle tabs correctly
 \newlength{\columnposn}
-\setlength{\gcolumnposn}{2.75in}
+\setlength{\gcolumnposn}{3.5in}
 \setlength{\columnposn}{\gcolumnposn}
 \newcommand{\C}[2][\@empty]{\ifx#1\@empty\else\global\setlength{\columnposn}{#1}\global\columnposn=\columnposn\fi\hfill\makebox[\textwidth-\columnposn][l]{\lst@basicstyle{\LstCommentStyle{#2}}}}
@@ -97 +104 @@
 }%
 \newcommand{\ETAL}{\abbrevFont{et}~\abbrevFont{al}}
-\newcommand*{\etal}{%
+\renewcommand*{\etal}{%
         \@ifnextchar{.}{\protect\ETAL}%
                 {\protect\ETAL.\xspace}%
@@ -145 +152 @@
 belowskip=3pt,
 % replace/adjust listing characters that look bad in sanserif
-literate={-}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.1ex}}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1
-        {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 {@}{\small{@}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
-        {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {->}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.075ex}}}\kern-0.2ex\textgreater}2,
+literate={-}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.1ex}}}}1 {^}{\raisebox{0.6ex}{$\scriptstyle\land\,$}}1
+        {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
+        {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {->}{\makebox[1ex][c]{\raisebox{0.5ex}{\rule{0.8ex}{0.075ex}}}\kern-0.2ex{\textgreater}}2,
 moredelim=**[is][\color{red}]{`}{`},
 }% lstset
-
-% inline code @...@
-\lstMakeShortInline@%
 
 \lstnewenvironment{cfa}[1][]
@@ -161 +165 @@
 {}
 
-
-\title{\protect\CFA : Adding Modern Programming Language Features to C}
-
-\author{Aaron Moss, Robert Schluntz, Peter Buhr}
-% \email{a3moss@uwaterloo.ca}
-% \email{rschlunt@uwaterloo.ca}
-% \email{pabuhr@uwaterloo.ca}
-% \affiliation{%
-%       \institution{University of Waterloo}
-%       \department{David R. Cheriton School of Computer Science}
-%       \streetaddress{Davis Centre, University of Waterloo}
-%       \city{Waterloo}
-%       \state{ON}
-%       \postcode{N2L 3G1}
-%       \country{Canada}
-% }
-
-%\terms{generic, tuple, variadic, types}
-%\keywords{generic types, tuple types, variadic types, polymorphic functions, C, Cforall}
-
-\begin{document}
-\maketitle
-
-
-\begin{abstract}
+% inline code @...@
+\lstMakeShortInline@%
+
+
+\title{\texorpdfstring{\protect\CFA : Adding Modern Programming Language Features to C}{Cforall : Adding Modern Programming Language Features to C}}
+
+\author[1]{Aaron Moss}
+\author[1]{Robert Schluntz}
+\author[1]{Peter A. Buhr*}
+\authormark{Aaron Moss \textsc{et al}}
+
+\address[1]{\orgdiv{David R. Cheriton School of Computer Science}, \orgname{University of Waterloo}, \orgaddress{\state{Ontario}, \country{Canada}}}
+
+\corres{*Peter A. Buhr, \email{pabuhr{\char`\@}uwaterloo.ca}}
+\presentaddress{David R. Cheriton School of Computer Science, University of Waterloo, Waterloo, ON, N2L 3G1, Canada}
+
+
+\abstract[Summary]{
 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems to hobby projects.
 This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
@@ -195 +192 @@
 This paper presents a quick tour of \CFA features showing how their design avoids shortcomings of similar features in C and other C-like languages.
 Finally, experimental results are presented to validate several of the new features.
-\end{abstract}
+}%
+
+\keywords{generic types, tuple types, variadic types, polymorphic functions, C, Cforall}
+
+
+\begin{document}
+\linenumbers                                            % comment out to turn off line numbering
+
+\maketitle
 
 
@@ -217 +222 @@
 Love it or hate it, C is extremely popular, highly used, and one of the few systems languages.
 In many cases, \CC is often used solely as a better C.
-Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive.
+Nevertheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive.
 
 \CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that aims to add modern language features to C while maintaining both source compatibility with C and a familiar programming model for programmers.
@@ -230 +235 @@
 \CFA is currently implemented as a source-to-source translator from \CFA to the gcc-dialect of C~\cite{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by gcc, meeting goals (1)--(3).
 Ultimately, a compiler is necessary for advanced features and optimal performance.
-All of the features discussed in this paper are working, unless a feature states it is a future feature for completion.
+All features discussed in this paper are working, unless otherwise stated as under construction.
 
 Finally, it is impossible to describe a programming language without usages before definitions.
@@ -258 +263 @@
 
 \begin{cfa}
-int max = 2147483647;                                           $\C[3.75in]{// (1)}$
+int max = 2147483647;                                   $\C[4in]{// (1)}$
 double max = 1.7976931348623157E+308;   $\C{// (2)}$
 int max( int a, int b ) { return a < b ? b : a; }  $\C{// (3)}$
 double max( double a, double b ) { return a < b ? b : a; }  $\C{// (4)}\CRT$
-max( 7, -max );                                                         $\C{// uses (3) and (1), by matching int from constant 7}$
-max( max, 3.14 );                                                       $\C{// uses (4) and (2), by matching double from constant 3.14}$
-max( max, -max );                                                       $\C{// ERROR: ambiguous}$
-int m = max( max, -max );                                       $\C{// uses (3) and (1) twice, by matching return type}$
+max( 7, -max );                                         $\C[2.75in]{// uses (3) and (1), by matching int from constant 7}$
+max( max, 3.14 );                                       $\C{// uses (4) and (2), by matching double from constant 3.14}$
+max( max, -max );                                       $\C{// ERROR: ambiguous}$
+int m = max( max, -max );                       $\C{// uses (3) and (1) twice, by matching return type}\CRT$
 \end{cfa}
 
@@ -292 +297 @@
 \begin{cfa}
 `forall( otype T )` T identity( T val ) { return val; }
-int forty_two = identity( 42 );                         $\C{// T is bound to int, forty\_two == 42}$
+int forty_two = identity( 42 );         $\C{// T is bound to int, forty\_two == 42}$
 \end{cfa}
 This @identity@ function can be applied to any complete \newterm{object type} (or @otype@).
@@ -306 +311 @@
 For example, the function @twice@ can be defined using the \CFA syntax for operator overloading:
 \begin{cfa}
-forall( otype T `| { T ?+?(T, T); }` ) T twice( T x ) { return x `+` x; }       $\C{// ? denotes operands}$
+forall( otype T `| { T ?+?(T, T); }` ) T twice( T x ) { return x `+` x; }  $\C{// ? denotes operands}$
 int val = twice( twice( 3.7 ) );
 \end{cfa}
@@ -325 +330 @@
 }
 double key = 5.0, vals[10] = { /* 10 sorted float values */ };
-double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp );      $\C{// search sorted array}$
+double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp ); $\C{// search sorted array}$
 \end{cfa}
 which can be augmented simply with a generalized, type-safe, \CFA-overloaded wrappers:
@@ -335 +340 @@
 forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) {
         T * result = bsearch( key, arr, size ); $\C{// call first version}$
-        return result ? result - arr : size;    $\C{// pointer subtraction includes sizeof(T)}$
-}
-double * val = bsearch( 5.0, vals, 10 );        $\C{// selection based on return type}$
+        return result ? result - arr : size; $\C{// pointer subtraction includes sizeof(T)}$
+}
+double * val = bsearch( 5.0, vals, 10 ); $\C{// selection based on return type}$
 int posn = bsearch( 5.0, vals, 10 );
 \end{cfa}
@@ -361 +366 @@
 forall( otype T | { int ?<?( T, T ); } ) void qsort( const T * arr, size_t size ) { /* use C qsort */ }
 {
-        int ?<?( double x, double y ) { return x `>` y; }       $\C{// locally override behaviour}$
+        int ?<?( double x, double y ) { return x `>` y; } $\C{// locally override behaviour}$
         qsort( vals, size );                                    $\C{// descending sort}$
 }
@@ -367 +372 @@
 Within the block, the nested version of @?<?@ performs @?>?@ and this local version overrides the built-in @?<?@ so it is passed to @qsort@.
 Hence, programmers can easily form local environments, adding and modifying appropriate functions, to maximize reuse of other existing functions and types.
+
+Under construction is a mechanism to distribute @forall@ over routines/types, where each block declaration is prefixed with the initial @forall@ clause significantly reducing duplication (see @stack@ examples in Section~\ref{sec:eval}):
+\begin{cfa}
+forall( otype `T` ) {                                                   $\C{// forall block}$
+        struct stack { stack_node(`T`) * head; };       $\C{// generic type}$
+        void push( stack(`T`) & s, `T` value ) ...      $\C{// generic operations}$
+        T pop( stack(`T`) & s ) ...
+}
+\end{cfa}
 
 
@@ -378 +392 @@
         T ?+=?( T *, T );
         T ++?( T * );
-        T ?++( T * ); };
-
+        T ?++( T * );
+};
 forall( otype T `| summable( T )` ) T sum( T a[$\,$], size_t size ) {  // use trait
         `T` total = { `0` };                                    $\C{// instantiate T from 0 by calling its constructor}$
         for ( unsigned int i = 0; i < size; i += 1 ) total `+=` a[i]; $\C{// select appropriate +}$
-        return total; }
+        return total;
+}
 \end{cfa}
 
@@ -392 +407 @@
         void ?{}( T &, T );                                             $\C{// copy constructor}$
         void ?=?( T &, T );                                             $\C{// assignment operator}$
-        void ^?{}( T & ); };                                    $\C{// destructor}$
+        void ^?{}( T & );                                               $\C{// destructor}$
+};
 \end{cfa}
 Given the information provided for an @otype@, variables of polymorphic type can be treated as if they were a complete type: stack-allocatable, default or copy-initialized, assigned, and deleted.
@@ -436 +452 @@
 One approach is to write bespoke data-structures for each context in which they are needed.
 While this approach is flexible and supports integration with the C type-checker and tooling, it is also tedious and error-prone, especially for more complex data structures.
-A second approach is to use @void *@ based polymorphism, \eg the C standard-library functions @bsearch@ and @qsort@, which allow reuse of code with common functionality.
+A second approach is to use @void *@-based polymorphism, \eg the C standard-library functions @bsearch@ and @qsort@, which allow reuse of code with common functionality.
 However, basing all polymorphism on @void *@ eliminates the type-checker's ability to ensure that argument types are properly matched, often requiring a number of extra function parameters, pointer indirection, and dynamic allocation that is not otherwise needed.
 A third approach to generic code is to use preprocessor macros, which does allow the generated code to be both generic and type-checked, but errors may be difficult to interpret.
@@ -526 +542 @@
 Results of these layout functions are cached so that they are only computed once per type per function. %, as in the example below for @pair@.
 Layout functions also allow generic types to be used in a function definition without reflecting them in the function signature.
-For instance, a function that strips duplicate values from an unsorted @vector(T)@ would likely have a pointer to the vector as its only explicit parameter, but use some sort of @set(T)@ internally to test for duplicate values.
+For instance, a function that strips duplicate values from an unsorted @vector(T)@ likely has a pointer to the vector as its only explicit parameter, but uses some sort of @set(T)@ internally to test for duplicate values.
 This function could acquire the layout for @set(T)@ by calling its layout function with the layout of @T@ implicitly passed into the function.
 
@@ -553 +569 @@
 struct litres {};
 
-forall( dtype U) scalar(U) ?+?( scalar(U) a, scalar(U) b ) {
+forall( dtype U ) scalar(U) ?+?( scalar(U) a, scalar(U) b ) {
         return (scalar(U)){ a.value + b.value };
 }
@@ -592 +608 @@
 [ q, r ] = div( 13.5, 5.2 );                            $\C{// assign into tuple}$
 \end{cfa}
-Clearly, this approach is straightforward to understand and use;
+This approach is straightforward to understand and use;
 therefore, why do few programming languages support this obvious feature or provide it awkwardly?
-The answer is that there are complex consequences that cascade through multiple aspects of the language, especially the type-system.
+To answer, there are complex consequences that cascade through multiple aspects of the language, especially the type-system.
 This section show these consequences and how \CFA handles them.
 
@@ -644 +660 @@
 p`->0` = 5;                                                                     $\C{// change quotient}$
 bar( qr`.1`, qr );                                                      $\C{// pass remainder and quotient/remainder}$
-rem = [div( 13, 5 ), 42]`.0.1`;                         $\C{// access 2nd component of 1st component of tuple expression}$
+rem = [div( 13, 5 ), 42]`.0.1`;                         $\C{// access 2nd component of 1st component}$
 \end{cfa}
 
@@ -653 +669 @@
 Tuple flattening recursively expands a tuple into the list of its basic components.
 Tuple structuring packages a list of expressions into a value of tuple type, \eg:
-%\lstDeleteShortInline@%
-%\par\smallskip
-%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
 \begin{cfa}
 int f( int, int );
-int g( [int, int] );
-int h( int, [int, int] );
+[int] g( [int, int] );
+[int] h( int, [int, int] );
 [int, int] x;
 int y;
-f( x );                 $\C{// flatten}$
-g( y, 10 );             $\C{// structure}$
-h( x, y );              $\C{// flatten and structure}$
-\end{cfa}
-%\end{cfa}
-%&
-%\begin{cfa}
-%\end{tabular}
-%\smallskip\par\noindent
-%\lstMakeShortInline@%
+f( x );                                                                         $\C{// flatten}$
+g( y, 10 );                                                                     $\C{// structure}$
+h( x, y );                                                                      $\C{// flatten and structure}$
+\end{cfa}
 In the call to @f@, @x@ is implicitly flattened so the components of @x@ are passed as the two arguments.
 In the call to @g@, the values @y@ and @10@ are structured into a single argument of type @[int, int]@ to match the parameter type of @g@.
@@ -682 +689 @@
 An assignment where the left side is a tuple type is called \newterm{tuple assignment}.
 There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a non-tuple type, called \newterm{multiple} and \newterm{mass assignment}, respectively.
-%\lstDeleteShortInline@%
-%\par\smallskip
-%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
 \begin{cfa}
 int x = 10;
@@ -694 +698 @@
 [y, x] = 3.14;                                                          $\C{// mass assignment}$
 \end{cfa}
-%\end{cfa}
-%&
-%\begin{cfa}
-%\end{tabular}
-%\smallskip\par\noindent
-%\lstMakeShortInline@%
 Both kinds of tuple assignment have parallel semantics, so that each value on the left and right side is evaluated before any assignments occur.
 As a result, it is possible to swap the values in two variables without explicitly creating any temporary variables or calling a function, \eg, @[x, y] = [y, x]@.
@@ -708 +706 @@
 This example shows mass, multiple, and cascading assignment used in one expression:
 \begin{cfa}
-void f( [int, int] );
+[void] f( [int, int] );
 f( [x, y] = z = 1.5 );                                          $\C{// assignments in parameter list}$
 \end{cfa}
@@ -723 +721 @@
 Here, the mass assignment sets all members of @s@ to zero.
 Since tuple-index expressions are a form of member-access expression, it is possible to use tuple-index expressions in conjunction with member tuple expressions to manually restructure a tuple (\eg rearrange, drop, and duplicate components).
-%\lstDeleteShortInline@%
-%\par\smallskip
-%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
 \begin{cfa}
 [int, int, long, double] x;
@@ -733 +728 @@
 [int, int, int] y = x.[2, 0, 2];                        $\C{// duplicate: [y.0, y.1, y.2] = [x.2, x.0.x.2]}$
 \end{cfa}
-%\end{cfa}
-%&
-%\begin{cfa}
-%\end{tabular}
-%\smallskip\par\noindent
-%\lstMakeShortInline@%
 It is also possible for a member access to contain other member accesses, \eg:
 \begin{cfa}
@@ -796 +785 @@
 Since @void@ is effectively a 0-element tuple, (3) discards the first and third return values, which is effectively equivalent to @[(int)(g().1.0), (int)(g().1.1)]@).
 
-Note that a cast is not a function call in \CFA, so flattening and structuring conversions do not occur for cast expressions\footnote{User-defined conversions have been considered, but for compatibility with C and the existing use of casts as type ascription, any future design for such conversions would require more precise matching of types than allowed for function arguments and parameters.}.
+Note that a cast is not a function call in \CFA, so flattening and structuring conversions do not occur for cast expressions\footnote{User-defined conversions have been considered, but for compatibility with C and the existing use of casts as type ascription, any future design for such conversions requires more precise matching of types than allowed for function arguments and parameters.}.
 As such, (4) is invalid because the cast target type contains 4 components, while the source type contains only 3.
 Similarly, (5) is invalid because the cast @([int, int, int])(g().1)@ is invalid.
@@ -813 +802 @@
 where @[5, "hello"]@ is flattened, giving argument list @5, "hello"@, and @T@ binds to @int@ and @U@ binds to @const char@.
 Tuples, however, may contain polymorphic components.
-For example, a plus operator can be written to add two triples together.
+For example, a plus operator can be written to sum two triples.
 \begin{cfa}
 forall( otype T | { T ?+?( T, T ); } ) [T, T, T] ?+?( [T, T, T] x, [T, T, T] y ) {
@@ -825 +814 @@
 Flattening and restructuring conversions are also applied to tuple types in polymorphic type assertions.
 \begin{cfa}
-int f( [int, double], double );
+[int] f( [int, double], double );
 forall( otype T, otype U | { T f( T, U, U ); } ) void g( T, U );
 g( 5, 10.21 );
@@ -836 +825 @@
 % \end{cfa}
 % so the thunk provides flattening and structuring conversions to inferred functions, improving the compatibility of tuples and polymorphism.
-% These thunks are generated locally using gcc nested-functions, rather hositing them to the external scope, so they can easily access local state.
+% These thunks are generated locally using gcc nested-functions, rather hoisting them to the external scope, so they can easily access local state.
 
 
@@ -847 +836 @@
 As such, @ttype@ variables are also called \newterm{argument packs}.
 
-Like variadic templates, the main way to manipulate @ttype@ polymorphic functions is via recursion.
+Like variadic templates, @ttype@ polymorphic functions are primarily manipulated via recursion.
 Since nothing is known about a parameter pack by default, assertion parameters are key to doing anything meaningful.
 Unlike variadic templates, @ttype@ polymorphic functions can be separately compiled.
-For example, a generalized @sum@ function written using @ttype@:
+For example, a generalized @sum@ function:
 \begin{cfa}
 int sum$\(_0\)$() { return 0; }
@@ -1028 +1017 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 case 2, 10, 34, 42:
@@ -1040 +1029 @@
 \lstMakeShortInline@%
 \end{cquote}
-for a contiguous list:\footnote{gcc has the same mechanism but awkward syntax, \lstinline@2 ...42@, because a space is required after a number, otherwise the period is a decimal point.}
+for a contiguous list:\footnote{gcc has the same mechanism but awkward syntax, \lstinline@2 ...42@, as a space is required after a number, otherwise the first period is a decimal point.}
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 case 2~42:
@@ -1060 +1049 @@
 \end{cfa}
 
-C allows placement of @case@ clauses \emph{within} statements nested in the @switch@ body (see Duff's device~\cite{Duff83});
+C allows placement of @case@ clauses \emph{within} statements nested in the @switch@ body (called Duff's device~\cite{Duff83});
 \begin{cfa}
 switch ( i ) {
@@ -1071 +1060 @@
 }
 \end{cfa}
-\CFA precludes this form of transfer into a control structure because it causes undefined behaviour, especially with respect to missed initialization, and provides very limited functionality.
+\CFA precludes this form of transfer \emph{into} a control structure because it causes undefined behaviour, especially with respect to missed initialization, and provides very limited functionality.
 
 C allows placement of declaration within the @switch@ body and unreachable code at the start, resulting in undefined behaviour:
@@ -1136 +1125 @@
 \end{figure}
 
-Finally, @fallthrough@ may appear in contexts other than terminating a @case@ clause, and have an explicit transfer label allowing separate cases but common final-code for a set of cases:
-\begin{cquote}
+Finally, Figure~\ref{f:FallthroughStatement} shows @fallthrough@ may appear in contexts other than terminating a @case@ clause, and have an explicit transfer label allowing separate cases but common final-code for a set of cases.
+The target label must be below the @fallthrough@ and may not be nested in a control structure, \ie @fallthrough@ cannot form a loop, and the target label must be at the same or higher level as the containing @case@ clause and located at the same level as a @case@ clause;
+the target label may be case @default@, but only associated with the current @switch@/@choose@ statement.
+
+\begin{figure}
+\centering
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
@@ -1159 +1152 @@
   case 4:
         ... `fallthrough common;`
-  common:
+  `common`: // below fallthrough at same level as case clauses
         ...      // common code for cases 3 and 4
         // implicit break
@@ -1166 +1159 @@
 \end{tabular}
 \lstMakeShortInline@%
-\end{cquote}
-The target label may be case @default@.
-
-Collectively, these control-structure enhancements reduce programmer burden and increase readability and safety.
+\caption{\lstinline|fallthrough| Statement}
+\label{f:FallthroughStatement}
+\end{figure}
 
 
@@ -1299 +1291 @@
         R r;
         ... `resume( r );` ...
-        ... r.fix // control does return here after handler
+        ... r.fix // control returns here after handler
 }
 `try` {
@@ -1412 +1404 @@
 
 
-\subsection{\texorpdfstring{\protect\lstinline{with} Clause / Statement}{with Clause / Statement}}
-\label{s:WithClauseStatement}
+\subsection{\texorpdfstring{\protect\lstinline{with} Statement}{with Statement}}
+\label{s:WithStatement}
 
 Grouping heterogeneous data into \newterm{aggregate}s (structure/union) is a common programming practice, and an aggregate can be further organized into more complex structures, such as arrays and containers:
@@ -1433 +1425 @@
 A similar situation occurs in object-oriented programming, \eg \CC:
 \begin{C++}
-class C {
+struct S {
         char c;                                                                 $\C{// fields}$
         int i;
         double d;
-        int f() {                                                               $\C{// implicit ``this'' aggregate}$
+        void f() {                                                              $\C{// implicit ``this'' aggregate}$
                 `this->`c; `this->`i; `this->`d;        $\C{// access containing fields}$
         }
 }
 \end{C++}
-Object-oriented nesting of member functions in a \lstinline[language=C++]@class@ allows eliding \lstinline[language=C++]@this->@ because of lexical scoping.
+Object-oriented nesting of member functions in a \lstinline[language=C++]@class/struct@ allows eliding \lstinline[language=C++]@this->@ because of lexical scoping.
 However, for other aggregate parameters, qualification is necessary:
 \begin{cfa}
 struct T { double m, n; };
-int C::f( T & t ) {                                                     $\C{// multiple aggregate parameters}$
-        c; i; d;                                                                $\C{\color{red}// this-\textgreater.c, this-\textgreater.i, this-\textgreater.d}$
+int S::f( T & t ) {                                                     $\C{// multiple aggregate parameters}$
+        c; i; d;                                                                $\C{\color{red}// this--{\textgreater}.c, this--{\textgreater}.i, this--{\textgreater}.d}$
         `t.`m; `t.`n;                                                   $\C{// must qualify}$
 }
@@ -1461 +1453 @@
 with the generality of opening multiple aggregate-parameters:
 \begin{cfa}
-int f( S & s, T & t ) `with ( s, t )` {         $\C{// multiple aggregate parameters}$
+void f( S & s, T & t ) `with ( s, t )` {                $\C{// multiple aggregate parameters}$
         c; i; d;                                                                $\C{\color{red}// s.c, s.i, s.d}$
         m; n;                                                                   $\C{\color{red}// t.m, t.n}$
@@ -1527 +1519 @@
 \begin{cfa}
 struct S { int i, j; } sv;
-with ( sv ) {                                                           $\C{implicit reference}$
+with ( sv ) {                                                           $\C{// implicit reference}$
         S & sr = sv;
-        with ( sr ) {                                                   $\C{explicit reference}$
+        with ( sr ) {                                                   $\C{// explicit reference}$
                 S * sp = &sv;
-                with ( *sp ) {                                          $\C{computed reference}$
-                        i = 3; j = 4;                                   $\C{\color{red}// sp-{\textgreater}i, sp-{\textgreater}j}$
+                with ( *sp ) {                                          $\C{// computed reference}$
+                        i = 3; j = 4;                                   $\C{\color{red}// sp--{\textgreater}i, sp--{\textgreater}j}$
                 }
                 i = 2; j = 3;                                           $\C{\color{red}// sr.i, sr.j}$
@@ -1539 +1531 @@
 }
 \end{cfa}
+
+Collectively, these control-structure enhancements reduce programmer burden and increase readability and safety.
 
 
@@ -1582 +1576 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 `[5] *` int x1;
@@ -1598 +1592 @@
 \begin{cfa}
 // array of 5 pointers to int
-// pointer to an array of 5 int
-// function returning pointer to an array of 5 int and taking an int
+// pointer to array of 5 int
+// function returning pointer to array of 5 int and taking int
 \end{cfa}
 \end{tabular}
@@ -1610 +1604 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 `*` int x, y;
@@ -1630 +1624 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{C}}      \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}     \\
 \begin{cfa}
 [ 5 ] int z;
@@ -1672 +1666 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
-\multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}     \\
 \begin{cfa}
 extern const * const int x;
-static const * [ 5 ] const int y;
+static const * [5] const int y;
 \end{cfa}
 &
 \begin{cfa}
 int extern const * const x;
-static const int (* const y)[ 5 ]
+static const int (* const y)[5]
 \end{cfa}
 &
@@ -1697 +1691 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 y = (* int)x;
@@ -1715 +1709 @@
 as well, parameter names are optional, \eg:
 \begin{cfa}
-[ int x ] f ( /* void */ );                                     $\C{// returning int with no parameters}$
-[ int x ] f (...);                                                      $\C{// returning int with unknown parameters}$
-[ * int ] g ( int y );                                          $\C{// returning pointer to int with int parameter}$
-[ void ] h ( int, char );                                       $\C{// returning no result with int and char parameters}$
-[ * int, int ] j ( int );                                       $\C{// returning pointer to int and int, with int parameter}$
+[ int x ] f ( /* void */ );             $\C[2.5in]{// returning int with no parameters}$
+[ int x ] f (...);                              $\C{// returning int with unknown parameters}$
+[ * int ] g ( int y );                  $\C{// returning pointer to int with int parameter}$
+[ void ] h ( int, char );               $\C{// returning no result with int and char parameters}$
+[ * int, int ] j ( int );               $\C{// returning pointer to int and int with int parameter}$
 \end{cfa}
 This syntax allows a prototype declaration to be created by cutting and pasting source text from the function-definition header (or vice versa).
@@ -1725 +1719 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 [double] foo(), foo( int ), foo( double ) {...}
@@ -1741 +1735 @@
 The syntax for pointers to \CFA functions specifies the pointer name on the right, \eg:
 \begin{cfa}
-* [ int x ] () fp;                                                      $\C{// pointer to function returning int with no parameters}$
-* [ * int ] ( int y ) gp;                                       $\C{// pointer to function returning pointer to int with int parameter}$
-* [ ] ( int, char ) hp;                                         $\C{// pointer to function returning no result with int and char parameters}$
-* [ * int, int ] ( int ) jp;                            $\C{// pointer to function returning pointer to int and int, with int parameter}$
+* [ int x ] () fp;                              $\C{// pointer to function returning int with no parameters}$
+* [ * int ] ( int y ) gp;               $\C{// pointer to function returning pointer to int with int parameter}$
+* [ ] ( int, char ) hp;                 $\C{// pointer to function returning no result with int and char parameters}$
+* [ * int, int ] ( int ) jp;    $\C{// pointer to function returning pointer to int and int with int parameter}$
 \end{cfa}
 Note, a function name cannot be specified:
 \begin{cfa}
-* [ int x ] f () fp;                                            $\C{// function name "f" is disallowed}$
+* [ int x ] f () fp;                    $\C{// function name "f" is disallowed}\CRT$
 \end{cfa}
 
@@ -1863 +1857 @@
 \begin{cfa}
 struct S { double x, y; };
-int i, j;
+int x, y;
 void f( int & i, int & j, S & s, int v[] );
-f( 3, i + j, (S){ 1.0, 7.0 }, (int [3]){ 1, 2, 3 } );   $\C{// pass rvalue to lvalue \(\Rightarrow\) implicit temporary}$
+f( 3, x + y, (S){ 1.0, 7.0 }, (int [3]){ 1, 2, 3 } ); $\C{// pass rvalue to lvalue \(\Rightarrow\) implicit temporary}$
 \end{cfa}
 This allows complex values to be succinctly and efficiently passed to functions, without the syntactic overhead of explicit definition of a temporary variable or the runtime cost of pass-by-value.
@@ -1952 +1946 @@
 
 One of the strengths (and weaknesses) of C is memory-management control, allowing resource release to be precisely specified versus unknown release with garbage-collected memory-management.
-However, this manual approach is often verbose, and it is useful to manage resources other than memory (\eg file handles) using the same mechanism as memory.
+However, this manual approach is verbose, and it is useful to manage resources other than memory (\eg file handles) using the same mechanism as memory.
 \CC addresses these issues using Resource Aquisition Is Initialization (RAII), implemented by means of \newterm{constructor} and \newterm{destructor} functions;
 \CFA adopts constructors and destructors (and @finally@) to facilitate RAII.
@@ -2004 +1998 @@
 {
         VLA  x,            y = { 20, 0x01 },     z = y; $\C{// z points to y}$
-        //      ?{}( x );  ?{}( y, 20, 0x01 );  ?{}( z, y ); 
+        //    ?{}( x );   ?{}( y, 20, 0x01 );    ?{}( z, y ); 
         ^x{};                                                                   $\C{// deallocate x}$
         x{};                                                                    $\C{// reallocate x}$
@@ -2052 +2046 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
 \begin{cfa}
 20_`hh`     // signed char
@@ -2105 +2099 @@
 
 For readability, it is useful to associate units to scale literals, \eg weight (stone, pound, kilogram) or time (seconds, minutes, hours).
-The left of Figure~\ref{f:UserLiteral} shows the \CFA alternative call-syntax (literal argument before function name), using the backquote, to convert basic literals into user literals.
+The left of Figure~\ref{f:UserLiteral} shows the \CFA alternative call-syntax (postfix: literal argument before function name), using the backquote, to convert basic literals into user literals.
 The backquote is a small character, making the unit (function name) predominate.
 For examples, the multi-precision integer-type in Section~\ref{s:MultiPrecisionIntegers} has user literals:
@@ -2113 +2107 @@
 y = "12345678901234567890123456789"|`mp| + "12345678901234567890123456789"|`mp|;
 \end{cfa}
-Because \CFA uses a standard function, all types and literals are applicable, as well as overloading and conversions.
+Because \CFA uses a standard function, all types and literals are applicable, as well as overloading and conversions, where @?`@ denotes a postfix-function name and @`@ denotes a postfix-function call.
 }%
+\begin{cquote}
+\lstset{language=CFA,moredelim=**[is][\color{red}]{|}{|},deletedelim=**[is][]{`}{`}}
+\lstDeleteShortInline@%
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{postfix function}}        & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{constant}}      & \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{variable/expression}}   & \multicolumn{1}{c}{\textbf{postfix pointer}}  \\
+\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}
+\lstMakeShortInline@%
+\end{cquote}
 
 The right of Figure~\ref{f:UserLiteral} shows the equivalent \CC version using the underscore for the call-syntax.
@@ -2136 +2169 @@
         return (W){ l.stones + r.stones };
 }
-W |?`st|( double w ) { return (W){ w }; }
-W |?`lb|( double w ) { return (W){ w / 14.0 }; }
-W |?`kg|( double w ) { return (W) { w * 0.16 }; }
+W |?`st|(double w) { return (W){ w }; }
+W |?`lb|(double w) { return (W){ w/14.0 }; }
+W |?`kg|(double w) { return (W){ w*0.16 }; }
 
 
@@ -2154 +2187 @@
 \begin{cfa}
 struct W {
-    double stones;
-    W() { stones = 0.0; }
-    W( double w ) { stones = w; }
+        double stones;
+        W() { stones = 0.0; }
+        W( double w ) { stones = w; }
 };
 W operator+( W l, W r ) {
         return W( l.stones + r.stones );
 }
-W |operator"" _st|( unsigned long long int w ) { return W( w ); }
-W |operator"" _lb|( unsigned long long int w ) { return W( w / 14.0 ); }
-W |operator"" _kg|( unsigned long long int w ) { return W( w * 0.16 ); }
-W |operator"" _st|( long double w ) { return W( w ); }
-W |operator"" _lb|( long double w ) { return W( w / 14.0 ); }
-W |operator"" _kg|( long double w ) { return W( w * 0.16 ); }
+W |operator""_st|(unsigned long long int w) {return W(w); }
+W |operator""_lb|(unsigned long long int w) {return W(w/14.0); }
+W |operator""_kg|(unsigned long long int w) {return W(w*0.16); }
+W |operator""_st|(long double w ) { return W( w ); }
+W |operator""_lb|(long double w ) { return W( w / 14.0 ); }
+W |operator""_kg|(long double w ) { return W( w * 0.16 ); }
 int main() {
         W w, heavy = { 20 };
@@ -2199 +2232 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{Definition}}       & \multicolumn{1}{c}{\textbf{Usage}}    \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}      & \multicolumn{1}{c}{\textbf{Usage}}    \\
 \begin{cfa}
 const short int `MIN` = -32768;
@@ -2218 +2251 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\lstset{basicstyle=\linespread{0.9}\sf\small}
-\begin{tabular}{@{}l@{\hspace{0.5\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{0.5\parindentlnth}}}{\textbf{\CFA}}  & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 MIN
+
 MAX
+
 PI
 E
@@ -2229 +2263 @@
 &
 \begin{cfa}
-SCHAR_MIN, CHAR_MIN, SHRT_MIN, INT_MIN, LONG_MIN, LLONG_MIN, FLT_MIN, DBL_MIN, LDBL_MIN
-SCHAR_MAX, UCHAR_MAX, SHRT_MAX, INT_MAX, LONG_MAX, LLONG_MAX, FLT_MAX, DBL_MAX, LDBL_MAX
+SCHAR_MIN, CHAR_MIN, SHRT_MIN, INT_MIN, LONG_MIN, LLONG_MIN,
+                FLT_MIN, DBL_MIN, LDBL_MIN
+SCHAR_MAX, UCHAR_MAX, SHRT_MAX, INT_MAX, LONG_MAX, LLONG_MAX,
+                FLT_MAX, DBL_MAX, LDBL_MAX
 M_PI, M_PIl
 M_E, M_El
@@ -2245 +2281 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{Definition}}       & \multicolumn{1}{c}{\textbf{Usage}}    \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}      & \multicolumn{1}{c}{\textbf{Usage}}    \\
 \begin{cfa}
 float `log`( float x );
@@ -2264 +2300 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 log
@@ -2292 +2328 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{Definition}}       & \multicolumn{1}{c}{\textbf{Usage}}    \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}      & \multicolumn{1}{c}{\textbf{Usage}}    \\
 \begin{cfa}
 unsigned int `abs`( int );
@@ -2311 +2347 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 abs
@@ -2331 +2367 @@
 The following shows one example where \CFA \emph{extends} an existing standard C interface to reduce complexity and provide safety.
 C/\Celeven provide a number of complex and overlapping storage-management operation to support the following capabilities:
-\begin{description}[topsep=3pt,itemsep=2pt,parsep=0pt]
+\begin{description}%[topsep=3pt,itemsep=2pt,parsep=0pt]
 \item[fill]
 an allocation with a specified character.
@@ -2381 +2417 @@
 \end{cfa}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 ip = alloc();
@@ -2403 +2439 @@
 ip = (int *)malloc( sizeof( int ) ); memset( ip, fill, dim * sizeof( int ) );
 ip = (int *)realloc( ip, 2 * dim * sizeof( int ) );
-ip = (int *)realloc( ip, 4 * dim * sizeof( int ) ); memset( ip, fill, 4 * dim * sizeof( int ) );
-
+ip = (int *)realloc( ip, 4 * dim * sizeof( int ) );
+                        memset( ip, fill, 4 * dim * sizeof( int ) );
 ip = memalign( 16, sizeof( int ) );
 ip = memalign( 16, sizeof( int ) ); memset( ip, fill, sizeof( int ) );
@@ -2441 +2477 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{\CC}}      \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{c}{\textbf{\CC}}      \\
 \begin{cfa}
 int x = 1, y = 2, z = 3;
@@ -2525 +2561 @@
 The \CFA interface wraps GMP functions into operator functions to make programming with multi-precision integers identical to using fixed-sized integers.
 The \CFA type name for multi-precision signed-integers is @Int@ and the header file is @gmp@.
-The following multi-precision factorial programs contrast using GMP with the \CFA and C interfaces.
-\begin{cquote}
+Figure~\ref{f:GMPInterface} shows a multi-precision factorial-program contrasting the GMP interface in \CFA and C.
+
+\begin{figure}
+\centering
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{@{\hspace{\parindentlnth}}c}{\textbf{C}}      \\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{@{\hspace{2\parindentlnth}}c}{\textbf{C}}     \\
 \begin{cfa}
 #include <gmp>
@@ -2557 +2595 @@
 \end{tabular}
 \lstMakeShortInline@%
-\end{cquote}
+\caption{GMP Interface \CFA versus C}
+\label{f:GMPInterface}
+\end{figure}
 
 
@@ -2566 +2606 @@
 In fact, \CFA's features for generic programming can enable faster runtime execution than idiomatic @void *@-based C code.
 This claim is demonstrated through a set of generic-code-based micro-benchmarks in C, \CFA, and \CC (see stack implementations in Appendix~\ref{sec:BenchmarkStackImplementation}).
-Since all these languages share a subset essentially comprising standard C, maximal-performance benchmarks would show little runtime variance, other than in length and clarity of source code.
-A more illustrative benchmark measures the costs of idiomatic usage of each language's features.
-Figure~\ref{fig:BenchmarkTest} shows the \CFA benchmark tests for a generic stack based on a singly linked-list, a generic pair-data-structure, and a variadic @print@ function similar to that in Section~\ref{sec:variadic-tuples}.
-The benchmark test is similar for C and \CC.
-The experiment uses element types @int@ and @pair(_Bool, char)@, and pushes $N=40M$ elements on a generic stack, copies the stack, clears one of the stacks, finds the maximum value in the other stack, and prints $N/2$ (to reduce graph height) constants.
+Since all these languages share a subset essentially comprising standard C, maximal-performance benchmarks should show little runtime variance, differing only in length and clarity of source code.
+A more illustrative comparison measures the costs of idiomatic usage of each language's features.
+Figure~\ref{fig:BenchmarkTest} shows the \CFA benchmark tests for a generic stack based on a singly linked-list.
+The benchmark test is similar for the other languages.
+The experiment uses element types @int@ and @pair(short, char)@, and pushes $N=40M$ elements on a generic stack, copies the stack, clears one of the stacks, and finds the maximum value in the other stack.
 
 \begin{figure}
 \begin{cfa}[xleftmargin=3\parindentlnth,aboveskip=0pt,belowskip=0pt]
-int main( int argc, char * argv[] ) {
+int main() {
         int max = 0, val = 42;
         stack( int ) si, ti;
 
         REPEAT_TIMED( "push_int", N, push( si, val ); )
-        TIMED( "copy_int", ti = si; )
+        TIMED( "copy_int", ti{ si }; )
         TIMED( "clear_int", clear( si ); )
         REPEAT_TIMED( "pop_int", N, int x = pop( ti ); if ( x > max ) max = x; )
 
-        pair( _Bool, char ) max = { (_Bool)0, '\0' }, val = { (_Bool)1, 'a' };
-        stack( pair( _Bool, char ) ) sp, tp;
+        pair( short, char ) max = { 0h, '\0' }, val = { 42h, 'a' };
+        stack( pair( short, char ) ) sp, tp;
 
         REPEAT_TIMED( "push_pair", N, push( sp, val ); )
-        TIMED( "copy_pair", tp = sp; )
+        TIMED( "copy_pair", tp{ sp }; )
         TIMED( "clear_pair", clear( sp ); )
-        REPEAT_TIMED( "pop_pair", N, pair(_Bool, char) x = pop( tp ); if ( x > max ) max = x; )
+        REPEAT_TIMED( "pop_pair", N, pair(short, char) x = pop( tp ); if ( x > max ) max = x; )
 }
 \end{cfa}
@@ -2600 +2640 @@
 hence runtime checks are necessary to safely down-cast objects.
 The most notable difference among the implementations is in memory layout of generic types: \CFA and \CC inline the stack and pair elements into corresponding list and pair nodes, while C and \CCV lack such a capability and instead must store generic objects via pointers to separately-allocated objects.
-For the print benchmark, idiomatic printing is used: the C and \CFA variants used @stdio.h@, while the \CC and \CCV variants used @iostream@; preliminary tests show this distinction has negligible runtime impact.
-Note, the C benchmark uses unchecked casts as there is no runtime mechanism to perform such checks, while \CFA and \CC provide type-safety statically.
+Note that the C benchmark uses unchecked casts as there is no runtime mechanism to perform such checks, while \CFA and \CC provide type-safety statically.
 
 Figure~\ref{fig:eval} and Table~\ref{tab:eval} show the results of running the benchmark in Figure~\ref{fig:BenchmarkTest} and its C, \CC, and \CCV equivalents.
 The graph plots the median of 5 consecutive runs of each program, with an initial warm-up run omitted.
-All code is compiled at \texttt{-O2} by gcc or g++ 6.2.0, with all \CC code compiled as \CCfourteen.
+All code is compiled at \texttt{-O2} by gcc or g++ 6.3.0, with all \CC code compiled as \CCfourteen.
 The benchmarks are run on an Ubuntu 16.04 workstation with 16 GB of RAM and a 6-core AMD FX-6300 CPU with 3.5 GHz maximum clock frequency.
 
@@ -2622 +2661 @@
 \begin{tabular}{rrrrr}
                                                                         & \CT{C}        & \CT{\CFA}     & \CT{\CC}      & \CT{\CCV}             \\ \hline
-maximum memory usage (MB)                       & 10001         & 2502          & 2503          & 11253                 \\
-source code size (lines)                        & 247           & 222           & 165           & 339                   \\
-redundant type annotations (lines)      & 39            & 2                     & 2                     & 15                    \\
-binary size (KB)                                        & 14            & 229           & 18            & 38                    \\
+maximum memory usage (MB)                       & 10,001        & 2,502         & 2,503         & 11,253                \\
+source code size (lines)                        & 196           & 186           & 125           & 290                   \\
+redundant type annotations (lines)      & 27            & 0                     & 2                     & 16                    \\
+binary size (KB)                                        & 14            & 257           & 14            & 37                    \\
 \end{tabular}
 \end{table}
 
 The C and \CCV variants are generally the slowest with the largest memory footprint, because of their less-efficient memory layout and the pointer-indirection necessary to implement generic types;
-this inefficiency is exacerbated by the second level of generic types in the pair-based benchmarks.
-By contrast, the \CFA and \CC variants run in roughly equivalent time for both the integer and pair of @_Bool@ and @char@ because the storage layout is equivalent, with the inlined libraries (\ie no separate compilation) and greater maturity of the \CC compiler contributing to its lead.
+this inefficiency is exacerbated by the second level of generic types in the pair benchmarks.
+By contrast, the \CFA and \CC variants run in roughly equivalent time for both the integer and pair of @short@ and @char@ because the storage layout is equivalent, with the inlined libraries (\ie no separate compilation) and greater maturity of the \CC compiler contributing to its lead.
 \CCV is slower than C largely due to the cost of runtime type-checking of down-casts (implemented with @dynamic_cast@);
-There are two outliers in the graph for \CFA: all prints and pop of @pair@.
-Both of these cases result from the complexity of the C-generated polymorphic code, so that the gcc compiler is unable to optimize some dead code and condense nested calls.
-A compiler designed for \CFA could easily perform these optimizations.
+The outlier in the graph for \CFA, pop @pair@, results from the complexity of the generated-C polymorphic code.
+The gcc compiler is unable to optimize some dead code and condense nested calls; a compiler designed for \CFA could easily perform these optimizations.
 Finally, the binary size for \CFA is larger because of static linking with the \CFA libraries.
 
-\CFA is also competitive in terms of source code size, measured as a proxy for programmer effort. The line counts in Table~\ref{tab:eval} include implementations of @pair@ and @stack@ types for all four languages for purposes of direct comparison, though it should be noted that \CFA and \CC have pre-written data structures in their standard libraries that programmers would generally use instead. Use of these standard library types has minimal impact on the performance benchmarks, but shrinks the \CFA and \CC benchmarks to 73 and 54 lines, respectively.
+\CFA is also competitive in terms of source code size, measured as a proxy for programmer effort. The line counts in Table~\ref{tab:eval} include implementations of @pair@ and @stack@ types for all four languages for purposes of direct comparison, though it should be noted that \CFA and \CC have pre-written data structures in their standard libraries that programmers would generally use instead. Use of these standard library types has minimal impact on the performance benchmarks, but shrinks the \CFA and \CC benchmarks to 39 and 42 lines, respectively.
+The difference between the \CFA and \CC line counts is primarily declaration duplication to implement separate compilation; a header-only \CFA library would be similar in length to the \CC version.
 On the other hand, C does not have a generic collections-library in its standard distribution, resulting in frequent reimplementation of such collection types by C programmers.
-\CCV does not use the \CC standard template library by construction, and in fact includes the definition of @object@ and wrapper classes for @bool@, @char@, @int@, and @const char *@ in its line count, which inflates this count somewhat, as an actual object-oriented language would include these in the standard library;
+\CCV does not use the \CC standard template library by construction, and in fact includes the definition of @object@ and wrapper classes for @char@, @short@, and @int@ in its line count, which inflates this count somewhat, as an actual object-oriented language would include these in the standard library;
 with their omission, the \CCV line count is similar to C.
 We justify the given line count by noting that many object-oriented languages do not allow implementing new interfaces on library types without subclassing or wrapper types, which may be similarly verbose.
 
-Raw line-count, however, is a fairly rough measure of code complexity;
-another important factor is how much type information the programmer must manually specify, especially where that information is not checked by the compiler.
-Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs, and is much less common in \CFA than C, with its manually specified function pointers arguments and format codes, or \CCV, with its extensive use of un-type-checked downcasts (\eg @object@ to @integer@ when popping a stack, or @object@ to @printable@ when printing the elements of a @pair@).
-To quantify this, the ``redundant type annotations'' line in Table~\ref{tab:eval} counts the number of lines on which the type of a known variable is re-specified, either as a format specifier, explicit downcast, type-specific function, or by name in a @sizeof@, struct literal, or @new@ expression.
+Line-count is a fairly rough measure of code complexity;
+another important factor is how much type information the programmer must specify manually, especially where that information is not compiler-checked.
+Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs, and is much less common in \CFA than C, with its manually specified function pointer arguments and format codes, or \CCV, with its extensive use of untype-checked downcasts, \eg @object@ to @integer@ when popping a stack.
+To quantify this manual typing, the ``redundant type annotations'' line in Table~\ref{tab:eval} counts the number of lines on which the type of a known variable is respecified, either as a format specifier, explicit downcast, type-specific function, or by name in a @sizeof@, struct literal, or @new@ expression.
 The \CC benchmark uses two redundant type annotations to create a new stack nodes, while the C and \CCV benchmarks have several such annotations spread throughout their code.
-The two instances in which the \CFA benchmark still uses redundant type specifiers are to cast the result of a polymorphic @malloc@ call (the @sizeof@ argument is inferred by the compiler).
-These uses are similar to the @new@ expressions in \CC, though the \CFA compiler's type resolver should shortly render even these type casts superfluous.
+The \CFA benchmark is able to eliminate all redundant type annotations through use of the polymorphic @alloc@ function discussed in Section~\ref{sec:libraries}.
 
 
@@ -2658 +2696 @@
 \subsection{Polymorphism}
 
-\CC is the most similar language to \CFA;
-both are extensions to C with source and runtime backwards compatibility.
-The fundamental difference is the engineering approach to maintain C compatibility and programmer expectation.
-While \CC provides good compatibility with C, it has a steep learning curve for many of its extensions.
-For example, polymorphism is provided via three disjoint mechanisms: overloading, inheritance, and templates.
+\CC provides three disjoint polymorphic extensions to C: overloading, inheritance, and templates.
 The overloading is restricted because resolution does not use the return type, inheritance requires learning object-oriented programming and coping with a restricted nominal-inheritance hierarchy, templates cannot be separately compiled resulting in compilation/code bloat and poor error messages, and determining how these mechanisms interact and which to use is confusing.
 In contrast, \CFA has a single facility for polymorphic code supporting type-safe separate-compilation of polymorphic functions and generic (opaque) types, which uniformly leverage the C procedural paradigm.
@@ -2717 +2751 @@
 
 
+\subsection{C Extensions}
+
+\CC is the best known C-based language, and is similar to \CFA in that both are extensions to C with source and runtime backwards compatibility.
+Specific difference between \CFA and \CC have been identified in prior sections, with a final observation that \CFA has equal or fewer tokens to express the same notion in many cases.
+The key difference in design philosophies is that \CFA is easier for C programmers to understand by maintaining a procedural paradigm and avoiding complex interactions among extensions.
+\CC, on the other hand, has multiple overlapping features (such as the three forms of polymorphism), many of which have complex interactions with its object-oriented design. 
+As a result, \CC has a steep learning curve for even experienced C programmers, especially when attempting to maintain performance equivalent to C legacy-code.
+
+There are several other C extension-languages with less usage and even more dramatic changes than \CC. 
+Objective-C and Cyclone are two other extensions to C with different design goals than \CFA, as discussed above. 
+Other languages extend C with more focused features. 
+$\mu$\CC~\cite{uC++book}, CUDA~\cite{Nickolls08}, ispc~\cite{Pharr12}, and Sierra~\cite{Leissa14} add concurrent or data-parallel primitives to C or \CC;
+data-parallel features have not yet been added to \CFA, but are easily incorporated within its design, while concurrency primitives similar to those in $\mu$\CC have already been added~\cite{Delisle18}.
+Finally, CCured~\cite{Necula02} and Ironclad \CC~\cite{DeLozier13} attempt to provide a more memory-safe C by annotating pointer types with garbage collection information; type-checked polymorphism in \CFA covers several of C's memory-safety issues, but more aggressive approaches such as annotating all pointer types with their nullability or requiring runtime garbage collection are contradictory to \CFA's backwards compatibility goals.
+
+
+\begin{comment}
 \subsection{Control Structures / Declarations / Literals}
 
@@ -2734 +2785 @@
 0/1 Literals \\
 user defined: D, Objective-C
+\end{comment}
 
 
@@ -2748 +2800 @@
 Finally, we demonstrate that \CFA performance for some idiomatic cases is better than C and close to \CC, showing the design is practically applicable.
 
-There is ongoing work on a wide range of \CFA feature extensions, including arrays with size, runtime type-information, virtual functions, user-defined conversions, concurrent primitives, and modules.
-(While all examples in the paper compile and run, a public beta-release of \CFA will take another 8--12 months to finalize these additional extensions.)
-In addition, there are interesting future directions for the polymorphism design.
+There is ongoing work on a wide range of \CFA features, including arrays with size, runtime type-information, virtual functions, user-defined conversions, concurrent primitives, and modules.
+While all examples in the paper compile and run, a public beta-release of \CFA will take another 8--12 months to finalize these extensions.
+There are also interesting future directions for the polymorphism design.
 Notably, \CC template functions trade compile time and code bloat for optimal runtime of individual instantiations of polymorphic functions.
 \CFA polymorphic functions use dynamic virtual-dispatch;
@@ -2761 +2813 @@
 \section{Acknowledgments}
 
-The authors would like to recognize the design assistance of Glen Ditchfield, Richard Bilson, Thierry Delisle, and Andrew Beach on the features described in this paper, and thank Magnus Madsen for feedback in the writing.
-This work is supported through a corporate partnership with Huawei Ltd.\ (\url{http://www.huawei.com}), and Aaron Moss and Peter Buhr are partially funded by the Natural Sciences and Engineering Research Council of Canada.
-
-% the first author's \grantsponsor{NSERC-PGS}{NSERC PGS D}{http://www.nserc-crsng.gc.ca/Students-Etudiants/PG-CS/BellandPostgrad-BelletSuperieures_eng.asp} scholarship.
-
-
-\bibliographystyle{plain}
+The authors would like to recognize the design assistance of Glen Ditchfield, Richard Bilson, Thierry Delisle, Andrew Beach and Brice Dobry on the features described in this paper, and thank Magnus Madsen for feedback on the writing.
+This work is supported by a corporate partnership with Huawei Ltd.\ (\url{http://www.huawei.com}), and Aaron Moss and Peter Buhr are partially funded by the Natural Sciences and Engineering Research Council of Canada.
+
+
 \bibliography{pl}
 
@@ -2776 +2825 @@
 \label{sec:BenchmarkStackImplementation}
 
-\lstset{basicstyle=\linespread{0.9}\sf\small}
-
-Throughout, @/***/@ designates a counted redundant type annotation.
+Throughout, @/***/@ designates a counted redundant type annotation; code reformatted for brevity.
 
 \smallskip\noindent
+C
+\begin{cfa}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt]
+struct stack_node {
+        void * value;
+        struct stack_node * next;
+};
+struct stack { struct stack_node* head; };
+void clear_stack( struct stack * s, void (*free_el)( void * ) ) {
+        for ( struct stack_node * next = s->head; next; ) {
+                struct stack_node * crnt = next;
+                next = crnt->next;
+                free_el( crnt->value );
+                free( crnt );
+        }
+        s->head = NULL;
+}
+struct stack new_stack() { return (struct stack){ NULL }; /***/ }
+void copy_stack( struct stack * s, const struct stack * t, void * (*copy)( const void * ) ) {
+        struct stack_node ** crnt = &s->head;
+        for ( struct stack_node * next = t->head; next; next = next->next ) {
+                *crnt = malloc( sizeof(struct stack_node) ); /***/
+                (*crnt)->value = copy( next->value );
+                crnt = &(*crnt)->next;
+        }
+        *crnt = NULL;
+}
+struct stack * assign_stack( struct stack * s, const struct stack * t, 
+                void * (*copy_el)( const void * ), void (*free_el)( void * ) ) {
+        if ( s->head == t->head ) return s;
+        clear_stack( s, free_el ); /***/
+        copy_stack( s, t, copy_el ); /***/
+        return s;
+}
+_Bool stack_empty( const struct stack * s ) { return s->head == NULL; }
+void push_stack( struct stack * s, void * v ) {
+        struct stack_node * n = malloc( sizeof(struct stack_node) ); /***/
+        *n = (struct stack_node){ v, s->head }; /***/
+        s->head = n;
+}
+void * pop_stack( struct stack * s ) {
+        struct stack_node * n = s->head;
+        s->head = n->next;
+        void * v = n->value;
+        free( n );
+        return v;
+}
+\end{cfa}
+
+\medskip\noindent
 \CFA
 \begin{cfa}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt]
-forall( otype T ) struct stack_node;
-forall( otype T ) struct stack {
-        stack_node(T) * head;
-};
 forall( otype T ) struct stack_node {
         T value;
         stack_node(T) * next;
 };
-forall( otype T) void ?{}( stack(T) & s ) { (s.head){ 0 }; }
-forall( otype T) void ?{}( stack(T) & s, stack(T) t ) {
+forall( otype T ) struct stack { stack_node(T) * head; };
+forall( otype T ) void clear( stack(T) & s ) with( s ) {
+        for ( stack_node(T) * next = head; next; ) {
+                stack_node(T) * crnt = next;
+                next = crnt->next;
+                ^(*crnt){};
+                free(crnt);
+        }
+        head = 0;
+}
+forall( otype T ) void ?{}( stack(T) & s ) { (s.head){ 0 }; }
+forall( otype T ) void ?{}( stack(T) & s, stack(T) t ) {
         stack_node(T) ** crnt = &s.head;
         for ( stack_node(T) * next = t.head; next; next = next->next ) {
-                stack_node(T) * new_node = ((stack_node(T)*)malloc());
-                (*new_node){ next->value }; /***/
-                *crnt = new_node;
-                stack_node(T) * acrnt = *crnt;
-                crnt = &acrnt->next;
+                *crnt = alloc();
+                ((*crnt)->value){ next->value };
+                crnt = &(*crnt)->next;
         }
         *crnt = 0;
@@ -2811 +2911 @@
 forall( otype T ) void ^?{}( stack(T) & s) { clear( s ); }
 forall( otype T ) _Bool empty( const stack(T) & s ) { return s.head == 0; }
-forall( otype T ) void push( stack(T) & s, T value ) {
-        stack_node(T) * new_node = ((stack_node(T)*)malloc());
-        (*new_node){ value, s.head }; /***/
-        s.head = new_node;
-}
-forall( otype T ) T pop( stack(T) & s ) {
-        stack_node(T) * n = s.head;
-        s.head = n->next;
+forall( otype T ) void push( stack(T) & s, T value ) with( s ) {
+        stack_node(T) * n = alloc();
+        (*n){ value, head };
+        head = n;
+}
+forall( otype T ) T pop( stack(T) & s ) with( s ) {
+        stack_node(T) * n = head;
+        head = n->next;
         T v = n->value;
-        delete( n );
+        ^(*n){};
+        free( n );
         return v;
 }
-forall( otype T ) void clear( stack(T) & s ) {
-        for ( stack_node(T) * next = s.head; next; ) {
-                stack_node(T) * crnt = next;
-                next = crnt->next;
-                delete( crnt );
+\end{cfa}
+
+\begin{comment}
+forall( otype T ) {
+        struct stack_node {
+                T value;
+                stack_node(T) * next;
+        };
+        struct stack { stack_node(T) * head; };
+        void clear( stack(T) & s ) with( s ) {
+                for ( stack_node(T) * next = head; next; ) {
+                        stack_node(T) * crnt = next;
+                        next = crnt->next;
+                        ^(*crnt){};
+                        free(crnt);
+                }
+                head = 0;
         }
-        s.head = 0;
-}
-\end{cfa}
+        void ?{}( stack(T) & s ) { (s.head){ 0 }; }
+        void ?{}( stack(T) & s, stack(T) t ) {
+                stack_node(T) ** crnt = &s.head;
+                for ( stack_node(T) * next = t.head; next; next = next->next ) {
+                        *crnt = alloc();
+                        ((*crnt)->value){ next->value };
+                        crnt = &(*crnt)->next;
+                }
+                *crnt = 0;
+        }
+        stack(T) ?=?( stack(T) & s, stack(T) t ) {
+                if ( s.head == t.head ) return s;
+                clear( s );
+                s{ t };
+                return s;
+        }
+        void ^?{}( stack(T) & s) { clear( s ); }
+        _Bool empty( const stack(T) & s ) { return s.head == 0; }
+        void push( stack(T) & s, T value ) with( s ) {
+                stack_node(T) * n = alloc();
+                (*n){ value, head };
+                head = n;
+        }
+        T pop( stack(T) & s ) with( s ) {
+                stack_node(T) * n = head;
+                head = n->next;
+                T v = n->value;
+                ^(*n){};
+                free( n );
+                return v;
+        }
+}
+\end{comment}
 
 \medskip\noindent
 \CC
 \begin{cfa}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt]
-template<typename T> class stack {
+template<typename T> struct stack {
         struct node {
                 T value;
                 node * next;
-                node( const T & v, node * n = nullptr ) : value(v), next(n) {}
+                node( const T & v, node * n = nullptr ) : value( v ), next( n ) {}
         };
         node * head;
-        void copy(const stack<T>& o) {
-                node ** crnt = &head;
-                for ( node * next = o.head;; next; next = next->next ) {
-                        *crnt = new node{ next->value }; /***/
-                        crnt = &(*crnt)->next;
-                }
-                *crnt = nullptr;
-        }
-  public:
-        stack() : head(nullptr) {}
-        stack(const stack<T>& o) { copy(o); }
-        stack(stack<T> && o) : head(o.head) { o.head = nullptr; }
-        ~stack() { clear(); }
-        stack & operator= (const stack<T>& o) {
-                if ( this == &o ) return *this;
-                clear();
-                copy(o);
-                return *this;
-        }
-        stack & operator= (stack<T> && o) {
-                if ( this == &o ) return *this;
-                head = o.head;
-                o.head = nullptr;
-                return *this;
-        }
-        bool empty() const { return head == nullptr; }
-        void push(const T & value) { head = new node{ value, head };  /***/ }
-        T pop() {
-                node * n = head;
-                head = n->next;
-                T x = std::move(n->value);
-                delete n;
-                return x;
-        }
+        stack() : head( nullptr ) {}
+        stack( const stack<T> & o ) { copy( o ); }
         void clear() {
                 for ( node * next = head; next; ) {
@@ -2885 +2996 @@
                 head = nullptr;
         }
+        void copy( const stack<T> & o ) {
+                node ** crnt = &head;
+                for ( node * next = o.head; next; next = next->next ) {
+                        *crnt = new node{ next->value }; /***/
+                        crnt = &(*crnt)->next;
+                }
+                *crnt = nullptr;
+        }
+        ~stack() { clear(); }
+        stack & operator= ( const stack<T> & o ) {
+                if ( this == &o ) return *this;
+                clear();
+                copy( o );
+                return *this;
+        }
+        bool empty() const { return head == nullptr; }
+        void push( const T & value ) { head = new node{ value, head };  /***/ }
+        T pop() {
+                node * n = head;
+                head = n->next;
+                T v = std::move( n->value );
+                delete n;
+                return v;
+        }
 };
-\end{cfa}
-
-\medskip\noindent
-C
-\begin{cfa}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt]
-struct stack_node {
-        void * value;
-        struct stack_node * next;
-};
-struct stack new_stack() { return (struct stack){ NULL }; /***/ }
-void copy_stack(struct stack * s, const struct stack * t, void * (*copy)(const void *)) {
-        struct stack_node ** crnt = &s->head;
-        for ( struct stack_node * next = t->head; next; next = next->next ) {
-                *crnt = malloc(sizeof(struct stack_node)); /***/
-                **crnt = (struct stack_node){ copy(next->value) }; /***/
-                crnt = &(*crnt)->next;
-        }
-        *crnt = 0;
-}
-_Bool stack_empty(const struct stack * s) { return s->head == NULL; }
-void push_stack(struct stack * s, void * value) {
-        struct stack_node * n = malloc(sizeof(struct stack_node)); /***/
-        *n = (struct stack_node){ value, s->head }; /***/
-        s->head = n;
-}
-void * pop_stack(struct stack * s) {
-        struct stack_node * n = s->head;
-        s->head = n->next;
-        void * x = n->value;
-        free(n);
-        return x;
-}
-void clear_stack(struct stack * s, void (*free_el)(void *)) {
-        for ( struct stack_node * next = s->head; next; ) {
-                struct stack_node * crnt = next;
-                next = crnt->next;
-                free_el(crnt->value);
-                free(crnt);
-        }
-        s->head = NULL;
-}
 \end{cfa}
 
@@ -2932 +3026 @@
 \CCV
 \begin{cfa}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt]
-stack::node::node( const object & v, node * n ) : value( v.new_copy() ), next( n ) {}
-void stack::copy(const stack & o) {
-        node ** crnt = &head;
-        for ( node * next = o.head; next; next = next->next ) {
-                *crnt = new node{ *next->value };
-                crnt = &(*crnt)->next;
+struct stack {
+        struct node {
+                ptr<object> value;
+                node * next;
+                node( const object & v, node * n = nullptr ) : value( v.new_copy() ), next( n ) {}
+        };
+        node * head;
+        void clear() {
+                for ( node * next = head; next; ) {
+                        node * crnt = next;
+                        next = crnt->next;
+                        delete crnt;
+                }
+                head = nullptr;
         }
-        *crnt = nullptr;
-}
-stack::stack() : head(nullptr) {}
-stack::stack(const stack & o) { copy(o); }
-stack::stack(stack && o) : head(o.head) { o.head = nullptr; }
-stack::~stack() { clear(); }
-stack & stack::operator= (const stack & o) {
-        if ( this == &o ) return *this;
-        clear();
-        copy(o);
-        return *this;
-}
-stack & stack::operator= (stack && o) {
-        if ( this == &o ) return *this;
-        head = o.head;
-        o.head = nullptr;
-        return *this;
-}
-bool stack::empty() const { return head == nullptr; }
-void stack::push(const object & value) { head = new node{ value, head }; /***/ }
-ptr<object> stack::pop() {
-        node * n = head;
-        head = n->next;
-        ptr<object> x = std::move(n->value);
-        delete n;
-        return x;
-}
-void stack::clear() {
-        for ( node * next = head; next; ) {
-                node * crnt = next;
-                next = crnt->next;
-                delete crnt;
+        void copy( const stack & o ) {
+                node ** crnt = &head;
+                for ( node * next = o.head; next; next = next->next ) {
+                        *crnt = new node{ *next->value }; /***/
+                        crnt = &(*crnt)->next;
+                }
+                *crnt = nullptr;
         }
-        head = nullptr;
-}
+        stack() : head( nullptr ) {}
+        stack( const stack & o ) { copy( o ); }
+        ~stack() { clear(); }
+        stack & operator= ( const stack & o ) {
+                if ( this == &o ) return *this;
+                clear();
+                copy( o );
+                return *this;
+        }
+        bool empty() const { return head == nullptr; }
+        void push( const object & value ) { head = new node{ value, head }; /***/ }
+        ptr<object> pop() {
+                node * n = head;
+                head = n->next;
+                ptr<object> v = std::move( n->value );
+                delete n;
+                return v;
+        }
+};
 \end{cfa}