Changeset 5a806be4

Timestamp:

Feb 22, 2018, 11:13:27 AM (7 years ago)

Author:

Rob Schluntz <rschlunt@…>

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, resolv-new, with_gc

Children:

df7a162

Parents:

a181494 (diff), 4ada74e (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:/u/cforall/software/cfa/cfa-cc

File:

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

doc/papers/general/Paper.tex

@@ -7 +7 @@
 \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}
@@ -142 +143 @@
 % 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 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}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,
 moredelim=**[is][\color{red}]{`}{`},
@@ -1072 +1073 @@
 
 Both labelled @continue@ and @break@ are a @goto@ restricted in the following ways:
-\begin{itemize}[topsep=3pt,itemsep=2pt,parsep=0pt]
+\begin{itemize}
 \item
 They cannot create a loop, which means only the looping constructs cause looping.
@@ -1290 +1291 @@
 The object is the implicit qualifier for the open structure-fields.
 
-All expressions in the expression list are open in ``parallel'' within the compound statement.
+All expressions in the expression list are open in parallel within the compound statement.
 This semantic is different from Pascal, which nests the openings from left to right.
 The difference between parallel and nesting occurs for fields with the same name and type:
@@ -1336 +1337 @@
 with ( (S)w ) { ... }                                           $\C{// unambiguous, cast}$
 \end{cfa}
-and @with@ expressions may be pointers and references (see Section~\ref{s:References}) to aggregates:
+and @with@ expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
 \begin{cfa}
 struct S { int i, j; } sv;
-with ( sv ) {                                                           $\C{variable}$
+with ( sv ) {                                                           $\C{implicit reference}$
         S & sr = sv;
-        with ( sr ) {                                                   $\C{reference}$
+        with ( sr ) {                                                   $\C{explicit reference}$
                 S * sp = &sv;
-                with ( *sp ) {                                          $\C{pointer}$
+                with ( *sp ) {                                          $\C{computed reference}$
                         i = 3; j = 4;                                   $\C{\color{red}// sp-{\textgreater}i, sp-{\textgreater}j}$
                 }
-                i = 3; j = 4;                                           $\C{\color{red}// sr.i, sr.j}$
+                i = 2; j = 3;                                           $\C{\color{red}// sr.i, sr.j}$
         }
-        i = 3; j = 4;                                                   $\C{\color{red}// sv.i, sv.j}$
+        i = 1; j = 2;                                                   $\C{\color{red}// sv.i, sv.j}$
 }
 \end{cfa}
@@ -1355 +1356 @@
 \subsection{Exception Handling}
 
-\CFA provides two forms of exception handling: \newterm{resumption} (fix-up) and \newterm{recovery}.
+\CFA provides two forms of exception handling: \newterm{resumption} (fix-up) and \newterm{recovery} (see Figure~\ref{f:CFAExceptionHandling}).
 Both mechanisms provide dynamic call to a handler using dynamic name-lookup, where fix-up has dynamic return and recovery has static return from the handler.
+\CFA restricts exception types to those defined by aggregate type @_Exception@.
+The form of the raise dictates the set of handlers examined during propagation: \newterm{resumption propagation} (@resume@) only examines resumption handlers (@catchResume@); \newterm{terminating propagation} (@throw@) only examines termination handlers (@catch@).
+If @resume@ or @throw@ have no exception type, it is a reresume/rethrow, meaning the currently exception continues propagation.
+If there is no current exception, the reresume/rethrow results in an error.
+
+\begin{figure}
 \begin{cquote}
 \lstDeleteShortInline@%
@@ -1362 +1369 @@
 \multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{Resumption}}       & \multicolumn{1}{c}{\textbf{Recovery}} \\
 \begin{cfa}
-_Exception E { int fix; };
+`_Exception R { int fix; };`
 void f() {
-        ... _Resume E;
-        // control returns here after handler
-try {
-        f();
-} catchResume( E e ) {
-        ... e.fix = ...; // return correction to raise
+        R r;
+        ... `resume( r );` ...
+        ... r.fix // control does return here after handler
+`try` {
+        ... f(); ...
+} `catchResume( R r )` {
+        ... r.fix = ...; // return correction to raise
 } // dynamic return to _Resume
 \end{cfa}
 &
 \begin{cfa}
-_Exception E {};
+`_Exception T {};`
 void f() {
-        ... _Throw E;
+
+        ... `throw( T{} );` ...
         // control does NOT return here after handler
-try {
-        f();
-} catch( E e ) {
+`try` {
+        ... f(); ...
+} `catch( T t )` {
         ... // recover and continue
 } // static return to next statement
@@ -1387 +1396 @@
 \lstMakeShortInline@%
 \end{cquote}
+\caption{\CFA Exception Handling}
+\label{f:CFAExceptionHandling}
+\end{figure}
+
+The set of exception types in a list of catch clause may include both a resumption and termination handler:
+\begin{cfa}
+try {
+        ... resume( `R{}` ); ...
+} catchResume( `R` r ) { ... throw( R{} ); ... } $\C{\color{red}// H1}$
+   catch( `R` r ) { ... }                                       $\C{\color{red}// H2}$
+
+\end{cfa}
+The resumption propagation raises @R@ and the stack is not unwound;
+the exception is caught by the @catchResume@ clause and handler H1 is invoked.
+The termination propagation in handler H1 raises @R@ and the stack is unwound;
+the exception is caught by the @catch@ clause and handler H2 is invoked.
+The termination handler is available because the resumption propagation did not unwind the stack.
+
+An additional feature is conditional matching in a catch clause:
+\begin{cfa}
+try {
+        ... write( `datafile`, ... ); ...               $\C{// may throw IOError}$
+        ... write( `logfile`, ... ); ...
+} catch ( IOError err; `err == datafile` ) { ... } $\C{// handle datafile error}$
+   catch ( IOError err; `err == logfile` ) { ... } $\C{// handle logfile error}$
+   catch ( IOError err ) { ... }                        $\C{// handler error from other files}$
+\end{cfa}
+where the throw inserts the failing file-handle in the I/O exception.
+Conditional catch cannot be trivially mimicked by other mechanisms because once an exception is caught, handler clauses in that @try@ statement are no longer eligible..
+
+The resumption raise can specify an alternate stack on which to raise an exception, called a \newterm{nonlocal raise}:
+\begin{cfa}
+resume [ $\emph{exception-type}$ ] [ _At $\emph{alternate-stack}$ ] ;
+\end{cfa}
+The @_At@ clause raises the specified exception or the currently propagating exception (reresume) at another coroutine or task~\cite{Delisle18}.
+Nonlocal raise is restricted to resumption to provide the exception handler the greatest flexibility because processing the exception does not unwind its stack, allowing it to continue after the handle returns.
+
+To facilitate nonlocal exception, \CFA provides dynamic enabling and disabling of nonlocal exception-propagation.
+The constructs for controlling propagation of nonlocal exceptions are the @enable@ and the @disable@ blocks:
+\begin{cquote}
+\lstDeleteShortInline@%
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\begin{cfa}
+enable $\emph{exception-type-list}$ {
+        // allow non-local resumption
+}
+\end{cfa}
+&
+\begin{cfa}
+disable $\emph{exception-type-list}$ {
+        // disallow non-local resumption
+}
+\end{cfa}
+\end{tabular}
+\lstMakeShortInline@%
+\end{cquote}
+The arguments for @enable@/@disable@ specify the exception types allowed to be propagated or postponed, respectively.
+Specifying no exception type is shorthand for specifying all exception types.
+Both @enable@ and @disable@ blocks can be nested, turning propagation on/off on entry, and on exit, the specified exception types are restored to their prior state.
+
+Finally, \CFA provides a Java like  @finally@ clause after the catch clauses:
+\begin{cfa}
+try {
+        ... f(); ...
+// catchResume or catch clauses
+} `finally` {
+        // house keeping
+}
+\end{cfa}
+The finally clause is always executed, i.e., if the try block ends normally or if an exception is raised.
+If an exception is raised and caught, the handler is run before the finally clause.
+Like a destructor (see Section~\ref{s:ConstructorsDestructors}), a finally clause can raise an exception but not if there is an exception being propagated.
+Mimicking the @finally@ clause with mechanisms like RAII is non-trivially when there are multiple types and local accesses.
 
 
 \section{Declarations}
 
-It is important that \CFA subjectively ``feel like'' C to programmers.
-An important part of this subjective feel is maintaining C's procedural paradigm, as opposed to the object-oriented paradigm of other systems languages such as \CC and Rust.
-Maintaining this procedural paradigm means that C coding-patterns remain not only functional but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development.
-Nonetheless, some features of object-oriented languages are undeniably convenient but are independent of object-oriented programming;
-\CFA adapts these features to a procedural paradigm.
+Declarations in C have weaknesses and omissions.
+\CFA attempts to correct and add to C declarations, while ensuring \CFA subjectively ``feels like'' C.
+An important part of this subjective feel is maintaining C's syntax and procedural paradigm, as opposed to functional and object-oriented approaches in other systems languages such as \CC and Rust.
+Maintaining the C approach means that C coding-patterns remain not only useable but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development.
+Nevertheless, some features from other approaches are undeniably convenient;
+\CFA attempts to adapt these features to the C paradigm.
 
 
@@ -1418 +1501 @@
 For example, a routine returning a pointer to an array of integers is defined and used in the following way:
 \begin{cfa}
-int `(*`f`())[`5`]` {...};                              $\C{// definition}$
- ... `(*`f`())[`3`]` += 1;                              $\C{// usage}$
+int `(*`f`())[`5`]` {...};                                      $\C{// definition}$
+ ... `(*`f`())[`3`]` += 1;                                      $\C{// usage}$
 \end{cfa}
 Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
@@ -1538 +1621 @@
 \lstMakeShortInline@%
 \end{cquote}
-All specifiers must appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
+Specifiers must appear at the start of a \CFA routine declaration\footnote{\label{StorageClassSpecifier}.
 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}}.
 
@@ -1562 +1645 @@
 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{// 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 routine definition header (or vice versa).
@@ -1588 +1671 @@
 The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
 \begin{cfa}
-* [ int x ] () fp;                                              $\C{// pointer to routine returning int with no parameters}$
-* [ * int ] ( int y ) gp;                               $\C{// pointer to routine returning pointer to int with int parameter}$
-* [ ] ( int, char ) hp;                                 $\C{// pointer to routine returning no result with int and char parameters}$
-* [ * int, int ] ( int ) jp;                    $\C{// pointer to routine returning pointer to int and int, with int parameter}$
+* [ int x ] () fp;                                                      $\C{// pointer to routine returning int with no parameters}$
+* [ * int ] ( int y ) gp;                                       $\C{// pointer to routine returning pointer to int with int parameter}$
+* [ ] ( int, char ) hp;                                         $\C{// pointer to routine returning no result with int and char parameters}$
+* [ * int, int ] ( int ) jp;                            $\C{// pointer to routine returning pointer to int and int, with int parameter}$
 \end{cfa}
 Note, \emph{a routine name cannot be specified}:
 \begin{cfa}
-* [ int x ] f () fp;                                    $\C{// routine name "f" is disallowed}$
+* [ int x ] f () fp;                                            $\C{// routine name "f" is disallowed}$
 \end{cfa}
 
@@ -1621 +1704 @@
 \begin{cfa}
 int x = 1, y = 2, * p1, * p2, ** p3;
-p1 = &x;                                                                $\C{// p1 points to x}$
-p2 = &y;                                                                $\C{// p2 points to y}$
-p3 = &p1;                                                               $\C{// p3 points to p1}$
+p1 = &x;                                                                        $\C{// p1 points to x}$
+p2 = &y;                                                                        $\C{// p2 points to y}$
+p3 = &p1;                                                                       $\C{// p3 points to p1}$
 *p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15);
 \end{cfa}
@@ -1635 +1718 @@
 \begin{cfa}
 int x = 1, y = 2, & r1, & r2, && r3;
-&r1 = &x;  $\C{// r1 points to x}$
-&r2 = &y;  $\C{// r2 points to y}$
-&&r3 = &&r1;  $\C{// r3 points to r2}$
+&r1 = &x;                                                                       $\C{// r1 points to x}$
+&r2 = &y;                                                                       $\C{// r2 points to y}$
+&&r3 = &&r1;                                                            $\C{// r3 points to r2}$
 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);       $\C{// implicit dereferencing}$
 \end{cfa}
@@ -1658 +1741 @@
 \begin{cfa}
 int & r = *new( int );
-...
+...                                                                                     $\C{// non-null reference}$
 delete &r;
-r += 1;                 // undefined reference
+r += 1;                                                                         $\C{// undefined reference}$
 \end{cfa}
 \end{lrbox}
 Rebinding allows \CFA references to be default-initialized (\eg to a null pointer\footnote{
-While effort has been put into non-null reference checking in \CC, the exercise seems moot for any non-managed languages, given that it only handles one of many different error situations:
+While effort has been made into non-null reference checking in \CC and Java, the exercise seems moot for any non-managed languages (C/\CC), given that it only handles one of many different error situations:
 \begin{cquote}
 \usebox{\LstBox}
@@ -1679 +1762 @@
 These explicit address-of operators can be thought of as ``cancelling out'' the implicit dereference operators, \eg @(&`*`)r1 = &x@ or @(&(&`*`)`*`)r3 = &(&`*`)r1@ or even @(&`*`)r2 = (&`*`)`*`r3@ for @&r2 = &r3@.
 More precisely:
-\begin{itemize}[topsep=3pt,itemsep=2pt,parsep=0pt]
+\begin{itemize}
 \item
 if @R@ is an rvalue of type {@T &@$_1 \cdots$@ &@$_r$} where $r \ge 1$ references (@&@ symbols) than @&R@ has type {@T `*`&@$_{\color{red}2} \cdots$@ &@$_{\color{red}r}$}, \\ \ie @T@ pointer with $r-1$ references (@&@ symbols).
@@ -1718 +1801 @@
 
 
+\subsection{Type Nesting}
+
+Nested types provide a mechanism to organize associated types and refactor a subset of fields into a named aggregate (\eg sub-aggregates @name@, @address@, @department@, within aggregate @employe@).
+Java nested types are dynamic (apply to objects), \CC are static (apply to the \lstinline[language=C++]@class@), and C hoists (refactors) nested types into the enclosing scope, meaning there is no need for type qualification.
+Since \CFA in not object-oriented, adopting dynamic scoping does not make sense;
+instead \CFA adopts \CC static nesting, using the field-selection operator ``@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``@::@'' (see Figure~\ref{f:TypeNestingQualification}).
+\begin{figure}
+\centering
+\lstDeleteShortInline@%
+\begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
+\hline
+\begin{cfa}
+struct S {
+        enum C { R, G, B };
+        struct T {
+                union U { int i, j; };
+                enum C c;
+                short int i, j;
+        };
+        struct T t;
+} s;
+
+int rtn() {
+        s.t.c = R;
+        struct T t = { R, 1, 2 };
+        enum C c;
+        union U u;
+}
+\end{cfa}
+&
+\begin{cfa}
+enum C { R, G, B };
+union U { int i, j; };
+struct T {
+        enum C c;
+        short int i, j;
+};
+struct S {
+        struct T t;
+} s;
+        
+
+
+
+
+
+
+\end{cfa}
+&
+\begin{cfa}
+struct S {
+        enum C { R, G, B };
+        struct T {
+                union U { int i, j; };
+                enum C c;
+                short int i, j;
+        };
+        struct T t;
+} s;
+
+int rtn() {
+        s.t.c = `S.`R;  // type qualification
+        struct `S.`T t = { `S.`R, 1, 2 };
+        enum `S.`C c;
+        union `S.T.`U u;
+}
+\end{cfa}
+\end{tabular}
+\lstMakeShortInline@%
+\caption{Type Nesting / Qualification}
+\label{f:TypeNestingQualification}
+\end{figure}
+In the C left example, types @C@, @U@ and @T@ are implicitly hoisted outside of type @S@ into the containing block scope.
+In the \CFA right example, the types are not hoisted and accessible.
+
+
 \subsection{Constructors and Destructors}
+\label{s:ConstructorsDestructors}
 
 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.
@@ -1729 +1890 @@
 
 In \CFA, a constructor is named @?{}@ and a destructor is named @^?{}@.
-The name @{}@ comes from the syntax for the initializer: @struct S { int i, j; } s = `{` 2, 3 `}`@.
-The symbol \lstinline+^+ is used because it was the last remaining binary operator that could be used in a unary context.
+The name @{}@ comes from the syntax for the initializer: @struct S { int i, j; } s = `{` 2, 3 `}`@\footnote{%
+The symbol \lstinline+^+ is used for the destructor name because it was the last binary operator that could be used in a unary context.}.
 Like other \CFA operators, these names represent the syntax used to call the constructor or destructor, \eg @?{}(x, ...)@ or @^{}(x, ...)@.
-The constructor and destructor have return type @void@ and a first parameter of reference to the object type to be constructed or destructs.
+The constructor and destructor have return type @void@, and the first parameter is a reference to the object type to be constructed or destructed.
 While the first parameter is informally called the @this@ parameter, as in object-oriented languages, any variable name may be used.
 Both constructors and destructors allow additional parametes after the @this@ parameter for specifying values for initialization/de-initialization\footnote{
@@ -1741 +1902 @@
 };
 void ?{}( VLA & vla ) with ( vla ) {            $\C{// default constructor}$
-        len = 10;  data = alloc( len );
+        len = 10;  data = alloc( len );                 $\C{// shallow copy}$
 }
 void ^?{}( VLA & vla ) with ( vla ) {           $\C{// destructor}$
@@ -1750 +1911 @@
 }                                                                                       $\C{// implicit:  ?\^{}\{\}( x );}$
 \end{cfa}
+(Note, the example is purposely kept simple by using shallow-copy semantics.)
 @VLA@ is a \newterm{managed type}\footnote{
 A managed type affects the runtime environment versus a self-contained type.}: a type requiring a non-trivial constructor or destructor, or with a field of a managed type. 
-A managed type is implicitly constructed upon allocation and destructed upon deallocation to ensure proper interaction with runtime resources, in this case the @data@ array in the heap. 
-For details of the placement of implicit constructor and destructor calls among complex executable statements see~\cite[\S~2.2]{Schluntz17}.
+A managed type is implicitly constructed at allocation and destructed at deallocation to ensure proper interaction with runtime resources, in this case, the @data@ array in the heap. 
+For details of the code-generation placement of implicit constructor and destructor calls among complex executable statements see~\cite[\S~2.2]{Schluntz17}.
 
 \CFA also provides syntax for \newterm{initialization} and \newterm{copy}:
@@ -1804 +1966 @@
 
 In some circumstance programmers may not wish to have constructor and destructor calls.
-In these cases, \CFA provides the initialization syntax \lstinline|S x @= {}|, and the object becomes unmanaged, so constructors and destructors calls are not generated. 
+In these cases, \CFA provides the initialization syntax \lstinline|S x @= {}|, and the object becomes unmanaged, so implicit constructor and destructor calls are not generated. 
 Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg \lstinline|VLA a @= { 0, 0x0 }|, with the usual C initialization semantics. 
 The point of \lstinline|@=| is to provide a migration path from legacy C code to \CFA, by providing a mechanism to incrementally convert to implicit initialization.
 
 
-\subsection{Type Nesting}
-
-\CFA allows \newterm{type nesting}, and type qualification of the nested types (see Figure~\ref{f:TypeNestingQualification}), where as C hoists (refactors) nested types into the enclosing scope and has no type qualification.
-\begin{figure}
-\centering
-\lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
-\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
-\hline
-\begin{cfa}
-struct S {
-        enum C { R, G, B };
-        struct T {
-                union U { int i, j; };
-                enum C c;
-                short int i, j;
-        };
-        struct T t;
-} s;
-
-int rtn() {
-        s.t.c = R;
-        struct T t = { R, 1, 2 };
-        enum C c;
-        union U u;
-}
-\end{cfa}
-&
-\begin{cfa}
-enum C { R, G, B };
-union U { int i, j; };
-struct T {
-        enum C c;
-        short int i, j;
-};
-struct S {
-        struct T t;
-} s;
-        
-
-
-
-
-
-
-\end{cfa}
-&
-\begin{cfa}
-struct S {
-        enum C { R, G, B };
-        struct T {
-                union U { int i, j; };
-                enum C c;
-                short int i, j;
-        };
-        struct T t;
-} s;
-
-int rtn() {
-        s.t.c = `S.`R;  // type qualification
-        struct `S.`T t = { `S.`R, 1, 2 };
-        enum `S.`C c;
-        union `S.T.`U u;
-}
-\end{cfa}
-\end{tabular}
-\lstMakeShortInline@%
-\caption{Type Nesting / Qualification}
-\label{f:TypeNestingQualification}
-\end{figure}
-In the left example in C, types @C@, @U@ and @T@ are implicitly hoisted outside of type @S@ into the containing block scope.
-In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``@::@''.
-
-
 % \subsection{Default Parameters}
 
@@ -1889 +1977 @@
 
 C already includes limited polymorphism for literals -- @0@ can be either an integer or a pointer literal, depending on context, while the syntactic forms of literals of the various integer and float types are very similar, differing from each other only in suffix.
-In keeping with the general \CFA approach of adding features while respecting ``the C way'' of doing things, we have extended both C's polymorphic zero and typed literal syntax to interoperate with user-defined types, while maintaining a backwards-compatible semantics.
+In keeping with the general \CFA approach of adding features while respecting the ``C-style'' of doing things, C's polymorphic constants and typed literal syntax are extended to interoperate with user-defined types, while maintaining a backwards-compatible semantics.
+A trivial example is allowing the underscore to separate prefixes, digits, and suffixes in all \CFA constants, as in Ada, \eg @0x`_`1.ffff`_`ffff`_`p`_`128`_`l@.
 
 
@@ -1906 +1995 @@
 
 
+\subsection{Integral Suffixes}
+
+Additional integral suffixes are added to cover all the integral types and lengths.
+\begin{cquote}
+\lstDeleteShortInline@%
+\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
+\begin{cfa}
+20_hh     // signed char
+21_hhu   // unsigned char
+22_h      // signed short int
+23_uh    // unsigned short int
+24z        // size_t
+\end{cfa}
+&
+\begin{cfa}
+20_L8     // int8_t
+21_ul8    // uint8_t
+22_l16    // int16_t
+23_ul16  // uint16_t
+24_l32    // int32_t
+\end{cfa}
+&
+\begin{cfa}
+25_ul32      // uint32_t
+26_l64        // int64_t
+27_l64u      // uint64_t
+26_L128     // int128
+27_L128u  // unsigned int128
+\end{cfa}
+\end{tabular}
+\lstMakeShortInline@%
+\end{cquote}
+
+
 \subsection{Units}
 
 Alternative call syntax (literal argument before routine name) to convert basic literals into user literals.
 
-{\lstset{language=CFA,deletedelim=**[is][]{`}{`},moredelim=**[is][\color{red}]{@}{@}}
+{\lstset{language=CFA,moredelim=**[is][\color{red}]{|}{|},deletedelim=**[is][]{`}{`}}
 \begin{cfa}
 struct Weight { double stones; };
-
 void ?{}( Weight & w ) { w.stones = 0; }        $\C{// operations}$
 void ?{}( Weight & w, double w ) { w.stones = w; }
 Weight ?+?( Weight l, Weight r ) { return (Weight){ l.stones + r.stones }; }
 
-Weight @?`st@( double w ) { return (Weight){ w }; } $\C{// backquote for units}$
-Weight @?`lb@( double w ) { return (Weight){ w / 14.0 }; }
-Weight @?`kg@( double w ) { return (Weight) { w * 0.1575}; }
+Weight |?`st|( double w ) { return (Weight){ w }; } $\C{// backquote for units}$
+Weight |?`lb|( double w ) { return (Weight){ w / 14.0 }; }
+Weight |?`kg|( double w ) { return (Weight) { w * 0.1575}; }
 
 int main() {
-        Weight w, hw = { 14 };                                  $\C{// 14 stone}$
-        w = 11@`st@ + 1@`lb@;
-        w = 70.3@`kg@;
-        w = 155@`lb@;
-        w = 0x_9b_u@`lb@;                                               $\C{// hexadecimal unsigned weight (155)}$
-        w = 0_233@`lb@;                                                 $\C{// octal weight (155)}$
-        w = 5@`st@ + 8@`kg@ + 25@`lb@ + hw;
+        Weight w, heavy = { 20 };                               $\C{// 20 stone}$
+        w = 155|`lb|;
+        w = 0x_9b_u|`lb|;                                               $\C{// hexadecimal unsigned weight (155)}$
+        w = 0_233|`lb|;                                                 $\C{// octal weight (155)}$
+        w = 5|`st| + 8|`kg| + 25|`lb| + heavy;
 }
 \end{cfa}
@@ -2032 +2152 @@
 \end{cquote}
 While \Celeven has type-generic math~\cite[\S~7.25]{C11} in @tgmath.h@ to provide a similar mechanism, these macros are limited, matching a routine name with a single set of floating type(s).
-For example, it is not possible to overload @atan@ for both one and two arguments;
+For example, it is impossible to overload @atan@ for both one and two arguments;
 instead the names @atan@ and @atan2@ are required.
 The key observation is that only a restricted set of type-generic macros are provided for a limited set of routine names, which do not generalize across the type system, as in \CFA.
@@ -2115 +2235 @@
 ip = alloc( ip, 2 * dim );
 ip = alloc( ip, 4 * dim, fill );
+
+ip = align_alloc( 16 );
+ip = align_alloc( 16, fill );
+ip = align_alloc( 16, dim );
+ip = align_alloc( 16, dim, fill );
 \end{cfa}
 &
@@ -2124 +2249 @@
 ip = (int *)realloc( ip, 2 * dim * sizeof( int ) );
 ip = (int *)realloc( ip, 4 * dim * sizeof( int ) ); memset( ip, fill, 4 * dim * sizeof( int ) );
-\end{cfa}
-\end{tabular}
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\begin{cfa}
-ip = align_alloc( 16 );
-ip = align_alloc( 16, fill );
-ip = align_alloc( 16, dim );
-ip = align_alloc( 16, dim, fill );
-\end{cfa}
-&
-\begin{cfa}
+
 ip = memalign( 16, sizeof( int ) );
 ip = memalign( 16, sizeof( int ) ); memset( ip, fill, sizeof( int ) );
@@ -2251 +2366 @@
 The implicit separator character (space/blank) is a separator not a terminator.
 The rules for implicitly adding the separator are:
-\begin{itemize}[topsep=3pt,itemsep=2pt,parsep=0pt]
+\begin{itemize}
 \item
 A separator does not appear at the start or end of a line.
@@ -2266 +2381 @@
 A separator does not appear before or after a C string beginning/ending with the quote or whitespace characters: \lstinline[basicstyle=\tt,showspaces=true]@`'": \t\v\f\r\n@
 }%
-\item
+\end{itemize}
 There are routines to set and get the separator string, and manipulators to toggle separation on and off in the middle of output.
-\end{itemize}
 
 
@@ -2287 +2401 @@
         sout | "Factorial Numbers" | endl;
         Int fact = 1;
-
         sout | 0 | fact | endl;
         for ( unsigned int i = 1; i <= 40; i += 1 ) {
@@ -2300 +2413 @@
 int main( void ) {
         `gmp_printf`( "Factorial Numbers\n" );
-        `mpz_t` fact;
-        `mpz_init_set_ui`( fact, 1 );
+        `mpz_t` fact;  `mpz_init_set_ui`( fact, 1 );
         `gmp_printf`( "%d %Zd\n", 0, fact );
         for ( unsigned int i = 1; i <= 40; i += 1 ) {