Changes in doc/user/user.tex [c6dc7f2:48b9b36]

File:

• doc/user/user.tex (modified) (171 diffs)

doc/user/user.tex

@@ -1 +1 @@
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%
+%% 
 %% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo
 %%
 %% The contents of this file are covered under the licence agreement in the
 %% file "LICENCE" distributed with Cforall.
-%%
-%% user.tex --
-%%
+%% 
+%% user.tex -- 
+%% 
 %% Author           : Peter A. Buhr
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
-%% Last Modified On : Sat Jul 13 18:36:18 2019
-%% Update Count     : 3876
+%% Last Modified On : Sun May  6 10:33:53 2018
+%% Update Count     : 3319
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -72 +72 @@
 
 % Names used in the document.
-\newcommand{\Version}{\input{build/version}}
+\newcommand{\Version}{\input{../../version}}
 \newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
 \newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
@@ -146 +146 @@
 \CFA adds many modern programming-language features that directly lead to increased \emph{\Index{safety}} and \emph{\Index{productivity}}, while maintaining interoperability with existing C programs and achieving similar performance.
 Like C, \CFA is a statically typed, procedural (non-\Index{object-oriented}) language with a low-overhead runtime, meaning there is no global \Index{garbage-collection}, but \Index{regional garbage-collection}\index{garbage-collection!regional} is possible.
-The primary new features include polymorphic routines and types, exceptions, concurrency, and modules.
+The primary new features include parametric-polymorphic routines and types, exceptions, concurrency, and modules.
 
 One of the main design philosophies of \CFA is to ``\Index{describe not prescribe}'', which means \CFA tries to provide a pathway from low-level C programming to high-level \CFA programming, but it does not force programmers to ``do the right thing''.
@@ -155 +155 @@
 As well, new programs can be written in \CFA using a combination of C and \CFA features.
 
-\Index*[C++]{\CC{}}~\cite{c++:v1} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
-However, \CC currently has the disadvantages of a strong object-oriented bias, multiple legacy design-choices that cannot be updated, and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
+\Index*[C++]{\CC{}} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
+However, \CC currently has the disadvantages of a strong object-oriented bias, multiple legacy design-choices that cannot be updated, and active divergence of the language model from C, all of which requires significant effort and training to incrementally add \CC to a C-based project.
 In contrast, \CFA has 30 years of hindsight and a clean starting point.
 
 Like \Index*[C++]{\CC{}}, there may be both an old and new ways to achieve the same effect.
-For example, the following programs compare the C, \CFA, and \CC I/O mechanisms, where the programs output the same result.
-\begin{center}
+For example, the following programs compare the \CFA, C, and \CC I/O mechanisms, where the programs output the same result.
+\begin{cquote}
 \begin{tabular}{@{}l@{\hspace{1.5em}}l@{\hspace{1.5em}}l@{}}
 \multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{C}} & \multicolumn{1}{c}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{\CC}}      \\
@@ -178 +178 @@
 int main( void ) {
         int x = 0, y = 1, z = 2;
-        ®sout | x | y | z;®§\indexc{sout}§
+        ®sout | x | y | z | endl;®§\indexc{sout}§
 }
 \end{cfa}
@@ -191 +191 @@
 \end{cfa}
 \end{tabular}
-\end{center}
+\end{cquote}
 While the \CFA I/O looks similar to the \Index*[C++]{\CC{}} output style, there are important differences, such as automatic spacing between variables as in \Index*{Python} (see~\VRef{s:IOLibrary}).
 
-
 \subsection{Background}
 
 This document is a programmer reference-manual for the \CFA programming language.
-The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of features.
+The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of each feature.
 The manual does not teach programming, \ie how to combine the new constructs to build complex programs.
-The reader must have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented, as well as some experience programming in C/\CC.
+A reader should already have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented, as well as some experience programming in C/\CC.
 Implementers should refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
 Changes to the syntax and additional features are expected to be included in later revisions.
@@ -207 +206 @@
 \section{Why fix C?}
 
-The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating-systems.
+The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems (especially UNIX 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.
 Even with all its problems, C continues to be popular because it allows writing software at virtually any level in a computer system without restriction.
 For system programming, where direct access to hardware, storage management, and real-time issues are a requirement, C is usually the only language of choice.
-The TIOBE index~\cite{TIOBE} for July 2018 ranks the top five most \emph{popular} programming languages as \Index*{Java} 16\%, C 14\%, \Index*[C++]{\CC{}} 7.5\%, Python 6\%, Visual Basic 4\% = 47.5\%, where the next 50 languages are less than 4\% each, with a long tail.
-The top 3 rankings over the past 30 years are:
+The TIOBE index~\cite{TIOBE} for March 2016 showed the following programming-language popularity: \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC{}} 6.7\%, \Csharp 4.3\%, \Index*{Python} 4.3\%, where the next 50 languages are less than 3\% each with a long tail.
+As well, for 30 years, C has been the number 1 and 2 most popular programming language:
 \begin{center}
-\setlength{\tabcolsep}{10pt}
-\begin{tabular}{@{}rccccccc@{}}
-                & 2018  & 2013  & 2008  & 2003  & 1998  & 1993  & 1988  \\ \hline
-Java    & 1             & 2             & 1             & 1             & 16    & -             & -             \\
-\R{C}   & \R{2} & \R{1} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} \\
-\CC             & 3             & 4             & 3             & 3             & 2             & 2             & 5             \\
+\setlength{\tabcolsep}{1.5ex}
+\begin{tabular}{@{}r|c|c|c|c|c|c|c@{}}
+Ranking & 2016  & 2011  & 2006  & 2001  & 1996  & 1991  & 1986          \\
+\hline
+Java    & 1             & 1             & 1             & 3             & 29    & -             & -                     \\
+\hline
+\R{C}   & \R{2} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} & \R{1}         \\
+\hline
+\CC             & 3             & 3             & 3             & 2             & 2             & 2             & 7                     \\
 \end{tabular}
 \end{center}
 Hence, C is still an extremely important programming language, with double the usage of \Index*[C++]{\CC{}}; in many cases, \CC is often used solely as a better C.
 Love it or hate it, C has been an important and influential part of computer science for 40 years and its appeal is not diminishing.
-Nevertheless, C has many problems and omissions that make it an unacceptable programming language for modern needs.
+Unfortunately, C has many problems and omissions that make it an unacceptable programming language for modern needs.
 
 As stated, the goal of the \CFA project is to engineer modern language-features into C in an evolutionary rather than revolutionary way.
@@ -234 +236 @@
 These languages have different syntax and semantics from C, do not interoperate directly with C, and are not systems languages because of restrictive memory-management or garbage collection.
 As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
-These costs can be prohibitive for many companies with a large software-base in C/\CC, and a significant number of programmers require retraining in the new programming language.
-
-The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixes many of the well known C problems while adding modern language-features.
-To achieve these goals required a significant engineering exercise, where we had to ``think inside the existing C box''.
-Without these significant extension to C, it is unable to cope with the needs of modern programming problems and programmers;
+These costs can be prohibitive for many companies with a large software-base in C/\CC, and a significant number of programmers require retraining to the new programming language.
+
+The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixes many of the well known C problems while containing modern language-features.
+Without significant extension to the C programming language, it is becoming unable to cope with the needs of modern programming problems and programmers;
 as a result, it will fade into disuse.
 Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language.
@@ -254 +255 @@
 \begin{lstlisting}
 ®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{lstlisting}
 % extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC{}} approach of object-oriented extensions.
@@ -282 +283 @@
 
 double key = 5.0, vals[10] = { /* 10 sorted floating 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{lstlisting}
 which can be augmented simply with a polymorphic, type-safe, \CFA-overloaded wrappers:
@@ -291 +292 @@
 
 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}§
+        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}§
 int posn = bsearch( 5.0, vals, 10 );
 \end{lstlisting}
@@ -306 +307 @@
 \begin{lstlisting}
 forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
-int * ip = malloc(); §\C{// select type and size from left-hand side}§
+int * ip = malloc();                                    §\C{// select type and size from left-hand side}§
 double * dp = malloc();
 struct S {...} * sp = malloc();
@@ -317 +318 @@
 Whereas, \CFA wraps each of these routines into ones with the overloaded name ©abs©:
 \begin{cfa}
-char ®abs®( char );
-extern "C" { int ®abs®( int ); } §\C{// use default C routine for int}§
-long int ®abs®( long int );
-long long int ®abs®( long long int );
-float ®abs®( float );
-double ®abs®( double );
-long double ®abs®( long double );
-float _Complex ®abs®( float _Complex );
-double _Complex ®abs®( double _Complex );
-long double _Complex ®abs®( long double _Complex );
+char abs( char );
+®extern "C" {® int abs( int ); ®}®              §\C{// use default C routine for int}§
+long int abs( long int );
+long long int abs( long long int );
+float abs( float );
+double abs( double );
+long double abs( long double );
+float _Complex abs( float _Complex );
+double _Complex abs( double _Complex );
+long double _Complex abs( long double _Complex );
 \end{cfa}
 The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
 Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
 Then overloading polymorphism uses a mechanism called \newterm{name mangling}\index{mangling!name} to create unique names that are different from C names, which are not mangled.
-Hence, there is the same need, as in \CC, to know if a name is a C or \CFA name, so it can be correctly formed.
-There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and types.
+Hence, there is the same need as in \CC, to know if a name is a C or \CFA name, so it can be correctly formed.
+There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
 
 This example strongly illustrates a core idea in \CFA: \emph{the \Index{power of a name}}.
@@ -349 +350 @@
 \begin{description}
 \item
-\Indexc{-std=gnu11}\index{compilation option!-std=gnu11@{©-std=gnu11©}}
-The 2011 C standard plus GNU extensions.
-\item
-\Indexc[deletekeywords=inline]{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{\lstinline[deletekeywords=inline]$-fgnu89-inline$}}
-Use the traditional GNU semantics for inline routines in C11 mode, which allows inline routines in header files.
+\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
+The 1999 C standard plus GNU extensions.
+\item
+\Indexc[deletekeywords=inline]{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{\lstinline[deletekeywords=inline]@-fgnu89-inline@}}
+Use the traditional GNU semantics for inline routines in C99 mode, which allows inline routines in header files.
 \end{description}
 The following new \CFA options are available:
@@ -426 +427 @@
 \begin{cfa}
 #ifndef __CFORALL__
-#include <stdio.h>§\indexc{stdio.h}§ §\C{// C header file}§
+#include <stdio.h>§\indexc{stdio.h}§    §\C{// C header file}§
 #else
-#include <fstream>§\indexc{fstream}§ §\C{// \CFA header file}§
+#include <fstream>§\indexc{fstream}§    §\C{// \CFA header file}§
 #endif
 \end{cfa}
-which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}.
-
-The \CFA translator has multiple steps.
-The following flags control how the tranlator works, the stages run, and printing within a stage.
-The majority of these flags are used by \CFA developers, but some are occasionally useful to programmers.
-\begin{description}[topsep=5pt,itemsep=0pt,parsep=0pt]
-\item
-\Indexc{-h}\index{translator option!-h@{©-h©}}, \Indexc{--help}\index{translator option!--help@{©--help©}} \, print help message
-\item
-\Indexc{-l}\index{translator option!-l@{©-l©}}, \Indexc{--libcfa}\index{translator option!--libcfa@{©--libcfa©}} \, generate libcfa.c
-\item
-\Indexc{-L}\index{translator option!-L@{©-L©}}, \Indexc{--linemarks}\index{translator option!--linemarks@{©--linemarks©}} \, generate line marks
-\item
-\Indexc{-m}\index{translator option!-m@{©-m©}}, \Indexc{--no-main}\index{translator option!--no-main@{©--no-main©}} \, do not replace main
-\item
-\Indexc{-N}\index{translator option!-N@{©-N©}}, \Indexc{--no-linemarks}\index{translator option!--no-linemarks@{©--no-linemarks©}} \, do not generate line marks
-\item
-\Indexc{-n}\index{translator option!-n@{©-n©}}, \Indexc{--no-prelude}\index{translator option!--no-prelude@{©--no-prelude©}} \, do not read prelude
-\item
-\Indexc{-p}\index{translator option!-p@{©-p©}}, \Indexc{--prototypes}\index{translator option!--prototypes@{©--prototypes©}} \, generate prototypes for prelude functions
-\item
-\Indexc{-P}\index{translator option!-P@{©-P©}}, \Indexc{--print}\index{translator option!--print@{©--print©}} \, one of:
-\begin{description}[topsep=0pt,itemsep=0pt,parsep=0pt]
-\item
-\Indexc{altexpr}\index{translator option!-P@{©-P©}!©altexpr©}\index{translator option!--print@{©-print©}!©altexpr©} \, alternatives for expressions
-\item
-\Indexc{ascodegen}\index{translator option!-P@{©-P©}!©ascodegen©}\index{translator option!--print@{©-print©}!©ascodegen©} \, as codegen rather than AST
-\item
-\Indexc{ast}\index{translator option!-P@{©-P©}!©ast©}\index{translator option!--print@{©-print©}!©ast©} \, AST after parsing
-\item
-\Indexc{astdecl}\index{translator option!-P@{©-P©}!©astdecl©}\index{translator option!--print@{©-print©}!©astdecl©} \, AST after declaration validation pass
-\item
-\Indexc{asterr}\index{translator option!-P@{©-P©}!©asterr©}\index{translator option!--print@{©-print©}!©asterr©} \, AST on error
-\item
-\Indexc{astexpr}\index{translator option!-P@{©-P©}!©astexpr©}\index{translator option!--print@{©-print©}!©altexpr©} \, AST after expression analysis
-\item
-\Indexc{astgen}\index{translator option!-P@{©-P©}!©astgen©}\index{translator option!--print@{©-print©}!©astgen©} \, AST after instantiate generics
-\item
-\Indexc{box}\index{translator option!-P@{©-P©}!©box©}\index{translator option!--print@{©-print©}!©box©} \, before box step
-\item
-\Indexc{ctordtor}\index{translator option!-P@{©-P©}!©ctordtor©}\index{translator option!--print@{©-print©}!©ctordtor©} \, after ctor/dtor are replaced
-\item
-\Indexc{codegen}\index{translator option!-P@{©-P©}!©codegen©}\index{translator option!--print@{©-print©}!©codegen©} \, before code generation
-\item
-\Indexc{declstats}\index{translator option!-P@{©-P©}!©declstats©}\index{translator option!--print@{©-print©}!©declstats©} \, code property statistics
-\item
-\Indexc{parse}\index{translator option!-P@{©-P©}!©parse©}\index{translator option!--print@{©-print©}!©parse©} \, yacc (parsing) debug information
-\item
-\Indexc{pretty}\index{translator option!-P@{©-P©}!©pretty©}\index{translator option!--print@{©-print©}!©pretty©} \, prettyprint for ascodegen flag
-\item
-\Indexc{resolver}\index{translator option!-P@{©-P©}!©resolver©}\index{translator option!--print@{©-print©}!©resolver©} \, before resolver step
-\item
-\Indexc{rproto}\index{translator option!-P@{©-P©}!©rproto©}\index{translator option!--print@{©-print©}!©rproto©} \, resolver-proto instance
-\item
-\Indexc{rsteps}\index{translator option!-P@{©-P©}!©rsteps©}\index{translator option!--print@{©-print©}!©rsteps©} \, resolver steps
-\item
-\Indexc{symevt}\index{translator option!-P@{©-P©}!©symevt©}\index{translator option!--print@{©-print©}!©symevt©} \, symbol table events
-\item
-\Indexc{tree}\index{translator option!-P@{©-P©}!©tree©}\index{translator option!--print@{©-print©}!©tree©} \, parse tree
-\item
-\Indexc{tuple}\index{translator option!-P@{©-P©}!©tuple©}\index{translator option!--print@{©-print©}!©tuple©} \, after tuple expansion
-\end{description}
-\item
-\Indexc{--prelude-dir} <directory> \, prelude directory for debug/nodebug
-\item
-\Indexc{-S}\index{translator option!-S@{©-S©}!©counters,heap,time,all,none©}, \Indexc{--statistics}\index{translator option!--statistics@{©--statistics©}!©counters,heap,time,all,none©} <option-list> \, enable profiling information:
-\begin{description}[topsep=0pt,itemsep=0pt,parsep=0pt]
-\item
-\Indexc{counters,heap,time,all,none}
-\end{description}
-\item
-\Indexc{-t}\index{translator option!-t@{©-t©}}, \Indexc{--tree}\index{translator option!--tree@{©--tree©}} build in tree
-\end{description}
-
-
-\section{Backquote Identifiers}
-\label{s:BackquoteIdentifiers}
-
-\CFA introduces several new keywords (see \VRef{s:CFAKeywords}) that can clash with existing C variable-names in legacy code.
-Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
-\begin{cfa}
-int ®`®otype®`® = 3; §\C{// make keyword an identifier}§
-double ®`®forall®`® = 3.5;
-\end{cfa}
-
-Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
-\VRef[Figure]{f:HeaderFileInterposition} shows how clashes in existing C header-files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©.
-Several common C header-files with keyword clashes are fixed in the standard \CFA header-library, so there is a seamless programming-experience.
-
-\begin{figure}
-\begin{cfa}
-// include file uses the CFA keyword "with".
-#if ! defined( with ) §\C{// nesting ?}§
-#define with ®`®with®`® §\C{// make keyword an identifier}§
-#define __CFA_BFD_H__
-#endif
-
-®#include_next <bfdlink.h> §\C{// must have internal check for multiple expansion}§
-®
-#if defined( with ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§
-#undef with
-#undef __CFA_BFD_H__
-#endif
-\end{cfa}
-\caption{Header-File Interposition}
-\label{f:HeaderFileInterposition}
-\end{figure}
+which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}. 
 
 
@@ -544 +439 @@
 Numeric constants are extended to allow \Index{underscore}s\index{constant!underscore}, \eg:
 \begin{cfa}
-2®_®147®_®483®_®648; §\C{// decimal constant}§
-56®_®ul; §\C{// decimal unsigned long constant}§
-0®_®377; §\C{// octal constant}§
-0x®_®ff®_®ff; §\C{// hexadecimal constant}§
-0x®_®ef3d®_®aa5c; §\C{// hexadecimal constant}§
-3.141®_®592®_®654; §\C{// floating constant}§
-10®_®e®_®+1®_®00; §\C{// floating constant}§
-0x®_®ff®_®ff®_®p®_®3; §\C{// hexadecimal floating}§
-0x®_®1.ffff®_®ffff®_®p®_®128®_®l; §\C{// hexadecimal floating long constant}§
-L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§; §\C{// wide character constant}§
+2®_®147®_®483®_®648;                                    §\C{// decimal constant}§
+56®_®ul;                                                                §\C{// decimal unsigned long constant}§
+0®_®377;                                                                §\C{// octal constant}§
+0x®_®ff®_®ff;                                                   §\C{// hexadecimal constant}§
+0x®_®ef3d®_®aa5c;                                               §\C{// hexadecimal constant}§
+3.141®_®592®_®654;                                              §\C{// floating constant}§
+10®_®e®_®+1®_®00;                                               §\C{// floating constant}§
+0x®_®ff®_®ff®_®p®_®3;                                   §\C{// hexadecimal floating}§
+0x®_®1.ffff®_®ffff®_®p®_®128®_®l;               §\C{// hexadecimal floating long constant}§
+L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§;     §\C{// wide character constant}§
 \end{cfa}
 The rules for placement of underscores are:
@@ -574 +469 @@
 
 
+\section{Backquote Identifiers}
+\label{s:BackquoteIdentifiers}
+
+\CFA introduces several new keywords (see \VRef{s:CFAKeywords}) that can clash with existing C variable-names in legacy code.
+Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
+\begin{cfa}
+int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
+double ®`®forall®`® = 3.5;
+\end{cfa}
+
+Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
+\VRef[Figure]{f:HeaderFileInterposition} shows how clashes in existing C header-files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©.
+Several common C header-files with keyword clashes are fixed in the standard \CFA header-library, so there is a seamless programming-experience.
+
+\begin{figure}
+\begin{cfa}
+// include file uses the CFA keyword "with".
+#if ! defined( with )                   §\C{// nesting ?}§
+#define with ®`®with®`®                 §\C{// make keyword an identifier}§
+#define __CFA_BFD_H__
+#endif
+
+®#include_next <bfdlink.h>              §\C{// must have internal check for multiple expansion}§
+®
+#if defined( with ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§
+#undef with
+#undef __CFA_BFD_H__
+#endif
+\end{cfa}
+\caption{Header-File Interposition}
+\label{f:HeaderFileInterposition}
+\end{figure}
+
+
 \section{Exponentiation Operator}
 
 C, \CC, and Java (and many other programming languages) have no exponentiation operator\index{exponentiation!operator}\index{operator!exponentiation}, \ie $x^y$, and instead use a routine, like \Indexc{pow}, to perform the exponentiation operation.
-\CFA extends the basic operators with the exponentiation operator ©?\?©\index{?\\?@©?\?©} and ©?\=?©\index{?\\=?@©\=?©}, as in, ©x \ y© and ©x \= y©, which means $x^y$ and $x \leftarrow x^y$.
+\CFA extends the basic operators with the exponentiation operator ©?\?©\index{?\\?@\lstinline@?\?@} and ©?\=?©\index{?\\=?@\lstinline@?\=?@}, as in, ©x \ y© and ©x \= y©, which means $x^y$ and $x \leftarrow x^y$.
 The priority of the exponentiation operator is between the cast and multiplicative operators, so that ©w * (int)x \ (int)y * z© is parenthesized as ©((w * (((int)x) \ ((int)y))) * z)©.
 
 As for \Index{division}, there are exponentiation operators for integral and floating types, including the builtin \Index{complex} types.
-Integral exponentiation\index{exponentiation!unsigned integral} is performed with repeated multiplication\footnote{The multiplication computation is $O(\log y)$.} (or shifting if the exponent is 2).
-Overflow from large exponents or negative exponents return zero.
-Floating exponentiation\index{exponentiation!floating} is performed using \Index{logarithm}s\index{exponentiation!logarithm}, so the exponent cannot be negative.
-\begin{cfa}
-sout | 1 ®\® 0 | 1 ®\® 1 | 2 ®\® 8 | -4 ®\® 3 | 5 ®\® 3 | 5 ®\® 32 | 5L ®\® 32 | 5L ®\® 64 | -4 ®\® -3 | -4.0 ®\® -3 | 4.0 ®\® 2.1
-           | (1.0f+2.0fi) ®\® (3.0f+2.0fi);
-1 1 256 -64 125 ®0® 3273344365508751233 ®0® ®0® -0.015625 18.3791736799526 0.264715-1.1922i
-\end{cfa}
-Note, ©5 ®\® 32© and ©5L ®\® 64© overflow, and ©-4 ®\® -3© is a fraction but stored in an integer so all three computations generate an integral zero.
-Parenthesis are necessary for complex constants or the expression is parsed as ©1.0f+®(®2.0fi \ 3.0f®)®+2.0fi©.
-The exponentiation operator is available for all the basic types, but for user-defined types, only the integral-computation version is available.
-\begin{cfa}
-forall( otype OT | { void ?{}( OT & this, one_t ); OT ?*?( OT, OT ); } )
-OT ?®\®?( OT ep, unsigned int y );
-forall( otype OT | { void ?{}( OT & this, one_t ); OT ?*?( OT, OT ); } )
-OT ?®\®?( OT ep, unsigned long int y );
-\end{cfa}
-The user type ©T© must define multiplication, one, ©1©, and, ©*©.
-
-
-\section{Control Structures}
-
-\CFA identifies inconsistent, problematic, and missing control structures in C, and extends, modifies, and adds control structures to increase functionality and safety.
-
-
-%\subsection{\texorpdfstring{\protect\lstinline@if@/\protect\lstinline@while@ Statement}{if Statement}}
-\subsection{\texorpdfstring{\LstKeywordStyle{if}/\LstKeywordStyle{while} Statement}{if/while Statement}}
-
-The ©if©/©while© expression allows declarations, similar to ©for© declaration expression.
-(Does not make sense for ©do©-©while©.)
-\begin{cfa}
-if ( ®int x = f()® ) ... §\C{// x != 0}§
-if ( ®int x = f(), y = g()® ) ... §\C{// x != 0 \&\& y != 0}§
-if ( ®int x = f(), y = g(); x < y® ) ... §\C{// relational expression}§
-if ( ®struct S { int i; } x = { f() }; x.i < 4® ) §\C{// relational expression}§
-
-while ( ®int x = f()® ) ... §\C{// x != 0}§
-while ( ®int x = f(), y = g()® ) ... §\C{// x != 0 \&\& y != 0}§
-while ( ®int x = f(), y = g(); x < y® ) ... §\C{// relational expression}§
-while ( ®struct S { int i; } x = { f() }; x.i < 4® ) ... §\C{// relational expression}§
-\end{cfa}
-Unless a relational expression is specified, each variable is compared not equal to 0, which is the standard semantics for the ©if©/©while© expression, and the results are combined using the logical ©&&© operator.\footnote{\CC only provides a single declaration always compared not equal to 0.}
-The scope of the declaration(s) is local to the @if@ statement but exist within both the ``then'' and ``else'' clauses.
-
-
-\subsection{Loop Control}
-
-The ©for©/©while©/©do-while© loop-control allows empty or simplified ranges (see Figure~\ref{f:LoopControlExamples}).
-\begin{itemize}
-\item
-An empty conditional implies ©1©.
-\item
-The up-to range ©~©\index{~@©~©} means exclusive range [M,N).
-\item
-The up-to range ©~=©\index{~=@©~=©} means inclusive range [M,N].
-\item
-The down-to range ©-~©\index{-~@©-~©} means exclusive range [N,M).
-\item
-The down-to range ©-~=©\index{-~=@©-~=©} means inclusive range [N,M].
-\item
-©@© means put nothing in this field.
-\item
-©0© is the implicit start value;
-\item
-©1© is the implicit increment value.
-\item
-The up-to range uses ©+=© for increment;
-\item
-The down-to range uses ©-=© for decrement.
-\item
-The loop index is polymorphic in the type of the start value or comparison value when start is implicitly ©0©.
-\end{itemize}
-
-\begin{figure}
-\begin{cquote}
-\begin{tabular}{@{}l|l@{}}
-\multicolumn{1}{c|}{loop control} & \multicolumn{1}{c}{output} \\
-\hline
-\begin{cfa}
-sout | nlOff;
-while ®()® { sout | "empty"; break; } sout | nl;
-do { sout | "empty"; break; } while ®()®; sout | nl;
-for ®()® { sout | "empty"; break; } sout | nl;
-for ( ®0® ) { sout | "A"; } sout | "zero" | nl;
-for ( ®1® ) { sout | "A"; } sout | nl;
-for ( ®10® ) { sout | "A"; } sout | nl;
-for ( ®1 ~= 10 ~ 2® ) { sout | "B"; } sout | nl;
-for ( ®10 -~= 1 ~ 2® ) { sout | "C"; } sout | nl;
-for ( ®0.5 ~ 5.5® ) { sout | "D"; } sout | nl;
-for ( ®5.5 -~ 0.5® ) { sout | "E"; } sout | nl;
-for ( ®i; 10® ) { sout | i; } sout | nl;
-for ( ®i; 1 ~= 10 ~ 2® ) { sout | i; } sout | nl;
-for ( ®i; 10 -~= 1 ~ 2® ) { sout | i; } sout | nl;
-for ( ®i; 0.5 ~ 5.5® ) { sout | i; } sout | nl;
-for ( ®i; 5.5 -~ 0.5® ) { sout | i; } sout | nl;
-for ( ®ui; 2u ~= 10u ~ 2u® ) { sout | ui; } sout | nl;
-for ( ®ui; 10u -~= 2u ~ 2u® ) { sout | ui; } sout | nl;
-enum { N = 10 };
-for ( ®N® ) { sout | "N"; } sout | nl;
-for ( ®i; N® ) { sout | i; } sout | nl;
-for ( ®i; N -~ 0® ) { sout | i; } sout | nl;
-const int start = 3, comp = 10, inc = 2;
-for ( ®i; start ~ comp ~ inc + 1® ) { sout | i; } sout | nl;
-for ( ®i; 1 ~ @® ) { if ( i > 10 ) break;
-        sout | i; } sout | nl;
-for ( ®i; 10 -~ @® ) { if ( i < 0 ) break;
-        sout | i; } sout | nl;
-for ( ®i; 2 ~ @ ~ 2® ) { if ( i > 10 ) break;
-        sout | i; } sout | nl;
-for ( ®i; 2.1 ~ @ ~ @® ) { if ( i > 10.5 ) break;
-        sout | i; i += 1.7; } sout | nl;
-for ( ®i; 10 -~ @ ~ 2® ) { if ( i < 0 ) break;
-        sout | i; } sout | nl;
-for ( ®i; 12.1 ~ @ ~ @® ) { if ( i < 2.5 ) break;
-        sout | i; i -= 1.7; } sout | nl;
-for ( ®i; 5 : j; -5 ~ @® ) { sout | i | j; } sout | nl;
-for ( ®i; 5 : j; -5 -~ @® ) { sout | i | j; } sout | nl;
-for ( ®i; 5 : j; -5 ~ @ ~ 2® ) { sout | i | j; } sout | nl;
-for ( ®i; 5 : j; -5 -~ @ ~ 2® ) { sout | i | j; } sout | nl;
-for ( ®j; -5 ~ @ : i; 5® ) { sout | i | j; } sout | nl;
-for ( ®j; -5 -~ @ : i; 5® ) { sout | i | j; } sout | nl;
-for ( ®j; -5 ~ @ ~ 2 : i; 5® ) { sout | i | j; } sout | nl;
-for ( ®j; -5 -~ @ ~ 2 : i; 5® ) { sout | i | j; } sout | nl;
-for ( ®j; -5 -~ @ ~ 2 : i; 5 : k; 1.5 ~ @® ) {
-        sout | i | j | k; } sout | nl;
-for ( ®j; -5 -~ @ ~ 2 : k; 1.5 ~ @ : i; 5® ) {
-        sout | i | j | k; } sout | nl;
-for ( ®k; 1.5 ~ @ : j; -5 -~ @ ~ 2 : i; 5® ) {
-        sout | i | j | k; } sout | nl;
-\end{cfa}
-&
-\begin{cfa}
-
-empty
-empty
-empty
-zero
-A
-A A A A A A A A A A
-B B B B B
-C C C C C
-D D D D D
-E E E E E
-0 1 2 3 4 5 6 7 8 9
-1 3 5 7 9
-10 8 6 4 2
-0.5 1.5 2.5 3.5 4.5
-5.5 4.5 3.5 2.5 1.5
-2 4 6 8 10
-10 8 6 4 2
-
-N N N N N N N N N N
-0 1 2 3 4 5 6 7 8 9
-10 9 8 7 6 5 4 3 2 1
-
-3 6 9
-
-1 2 3 4 5 6 7 8 9 10
-
-10 9 8 7 6 5 4 3 2 1 0
-
-2 4 6 8 10
-
-2.1 3.8 5.5 7.2 8.9
-
-10 8 6 4 2 0
-
-12.1 10.4 8.7 7 5.3 3.6
-0 -5 1 -4 2 -3 3 -2 4 -1
-0 -5 1 -6 2 -7 3 -8 4 -9
-0 -5 1 -3 2 -1 3 1 4 3
-0 -5 1 -7 2 -9 3 -11 4 -13
-0 -5 1 -4 2 -3 3 -2 4 -1
-0 -5 1 -6 2 -7 3 -8 4 -9
-0 -5 1 -3 2 -1 3 1 4 3
-0 -5 1 -7 2 -9 3 -11 4 -13
-
-0 -5 1.5 1 -7 2.5 2 -9 3.5 3 -11 4.5 4 -13 5.5
-
-0 -5 1.5 1 -7 2.5 2 -9 3.5 3 -11 4.5 4 -13 5.5
-
-0 -5 1.5 1 -7 2.5 2 -9 3.5 3 -11 4.5 4 -13 5.5
-\end{cfa}
-\end{tabular}
-\end{cquote}
-\caption{Loop Control Examples}
-\label{f:LoopControlExamples}
-\end{figure}
-
-
-%\section{\texorpdfstring{\protect\lstinline@switch@ Statement}{switch Statement}}
-\subsection{\texorpdfstring{\LstKeywordStyle{switch} Statement}{switch Statement}}
-
-C allows a number of questionable forms for the ©switch© statement:
-\begin{enumerate}
-\item
-By default, the end of a ©case© clause\footnote{
-In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
-\emph{falls through} to the next ©case© clause in the ©switch© statement;
-to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
-\begin{cfa}
-switch ( i ) {
-  case 1:
-        ...
-        // fall-through
-  case 2:
-        ...
-        break;  // exit switch statement
-}
-\end{cfa}
-The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
-\begin{cquote}
-\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
-\begin{cfa}
-switch ( argc ) {
-  case 3:
-        // open output file
-        // fall-through
-  case 2:
-        // open input file
-        break;  // exit switch statement
-  default:
-        // usage message
-}
-\end{cfa}
-&
-\begin{cfa}
-
-if ( argc == 3 ) {
-        // open output file
-        ®// open input file
-®} else if ( argc == 2 ) {
-        ®// open input file (duplicate)
-
-®} else {
-        // usage message
-}
-\end{cfa}
-\end{tabular}
-\end{cquote}
-In this example, case 2 is always done if case 3 is done.
-This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
-C also uses fall-through to handle multiple case-values resulting in the same action:
-\begin{cfa}
-switch ( i ) {
-  ®case 1: case 3: case 5:®     // odd values
-        // odd action
-        break;
-  ®case 2: case 4: case 6:®     // even values
-        // even action
-        break;
-}
-\end{cfa}
-However, this situation is handled in other languages without fall-through by allowing a list of case values.
-While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
-Hence, default fall-through semantics results in a large number of programming errors as programmers often \emph{forget} the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
-
-\item
-It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
-\begin{cfa}
-switch ( i ) {
-  case 0:
-        if ( j < k ) {
-                ...
-          ®case 1:®             // transfer into "if" statement
-                ...
-        } // if
-  case 2:
-        while ( j < 5 ) {
-                ...
-          ®case 3:®             // transfer into "while" statement
-                ...
-        } // while
-} // switch
-\end{cfa}
-The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
-The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
-The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
-There are no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
-Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
-\begin{cfa}
-register int n = (count + 7) / 8;
-switch ( count % 8 ) {
-case 0: do{ *to = *from++;
-case 7:         *to = *from++;
-case 6:         *to = *from++;
-case 5:         *to = *from++;
-case 4:         *to = *from++;
-case 3:         *to = *from++;
-case 2:         *to = *from++;
-case 1:         *to = *from++;
-                } while ( --n > 0 );
-}
-\end{cfa}
-which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
-While efficient, this sort of special purpose usage is questionable:
-\begin{quote}
-Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
-discovery.~\cite{Duff83}
-\end{quote}
-\item
-It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
-Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
-The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
-hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
-This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
-
-\item
-It is possible to place unreachable code at the start of a ©switch© statement, as in:
-\begin{cfa}
-switch ( x ) {
-        ®int y = 1;® §\C{// unreachable initialization}§
-        ®x = 7;® §\C{// unreachable code without label/branch}§
-  case 0: ...
-        ...
-        ®int z = 0;® §\C{// unreachable initialization, cannot appear after case}§
-        z = 2;
-  case 1:
-        ®x = z;® §\C{// without fall through, z is uninitialized}§
-}
-\end{cfa}
-While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
-Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
-As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
-The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
-\end{enumerate}
-
-Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
-\begin{itemize}
-\item
-the number of ©switch© statements is small,
-\item
-most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
-\item
-the ©default© clause is usually written as the last case-clause,
-\item
-and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
-\end{itemize}
-These observations put into perspective the \CFA changes to the ©switch©.
-\begin{enumerate}
-\item
-Eliminating default fall-through has the greatest potential for affecting existing code.
-However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
-\begin{cfa}
-case 1:  case 2:  case 3: ...
-\end{cfa}
-still works.
-Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
-Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, \eg:
-\begin{cfa}
-®choose® ( i ) {
-  case 1:  case 2:  case 3:
-        ...
-        ®// implicit end of switch (break)
-  ®case 5:
-        ...
-        ®fallthru®; §\C{// explicit fall through}§
-  case 7:
-        ...
-        ®break® §\C{// explicit end of switch (redundant)}§
-  default:
-        j = 3;
-}
-\end{cfa}
-Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
-An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
-An explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
-As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
-\item
-\Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
-Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
-\item
-The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end.
-Therefore, no change is made for this issue.
-\item
-Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{
-Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
-Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
-\begin{cfa}
-switch ( x ) {
-        ®int i = 0;® §\C{// allowed only at start}§
-  case 0:
-        ...
-        ®int j = 0;® §\C{// disallowed}§
-  case 1:
-        {
-                ®int k = 0;® §\C{// allowed at different nesting levels}§
-                ...
-          ®case 2:® §\C{// disallow case in nested statements}§
-        }
-  ...
-}
-\end{cfa}
-\end{enumerate}
-
-
-%\section{\texorpdfstring{\protect\lstinline@case@ Clause}{case Clause}}
-\subsection{\texorpdfstring{\LstKeywordStyle{case} Statement}{case Statement}}
-
-C restricts the ©case© clause of a ©switch© statement to a single value.
-For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
-Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
-Therefore, the ©case© clause is extended with a list of values, as in:
-\begin{cquote}
-\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
-\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
-\begin{cfa}
-switch ( i ) {
-  case ®1, 3, 5®:
-        ...
-  case ®2, 4, 6®:
-        ...
-}
-\end{cfa}
-&
-\begin{cfa}
-switch ( i ) {
-  case 1: case 3 : case 5:
-        ...
-  case 2: case 4 : case 6:
-        ...
-}
-\end{cfa}
-&
-\begin{cfa}
-
-// odd values
-
-// even values
-
-
-\end{cfa}
-\end{tabular}
-\end{cquote}
-In addition, subranges are allowed to specify case values.\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.}
-\begin{cfa}
-switch ( i ) {
-  case ®1~5:® §\C{// 1, 2, 3, 4, 5}§
-        ...
-  case ®10~15:® §\C{// 10, 11, 12, 13, 14, 15}§
-        ...
-}
-\end{cfa}
-Lists of subranges are also allowed.
-\begin{cfa}
-case ®1~5, 12~21, 35~42®:
-\end{cfa}
-
-
-% for ()  => for ( ;; )
-% for ( 10 - t ) => for ( typeof(10 - t) ? = 0 ; ? < 10 - t; ? += 1 ) // using 0 and 1
-% for ( i ; 10 - t ) => for ( typeof(10 - t) i = 0 ; i < 10 - t; i += 1 ) // using 0 and 1
-% for ( T i ; 10 - t ) => for ( T i = 0 ; i < 10 - t; i += 1 ) // using 0 and 1
-% for ( 3~9 ) => for ( int ? = 3 ; ? < 9; ? += 1 ) // using 1
-% for ( i ; 3~9 ) => for ( int i = 3 ; i < 9; i += 1 ) // using 1
-% for ( T i ; 3~9 ) => for ( T i = 3 ; i < 9; i += 1 ) // using 1
-
-
-%\subsection{\texorpdfstring{Labelled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labelled continue / break}}
-\subsection{\texorpdfstring{Labelled \LstKeywordStyle{continue} / \LstKeywordStyle{break} Statement}{Labelled continue / break Statement}}
+Unsigned integral exponentiation\index{exponentiation!unsigned integral} is performed with repeated multiplication\footnote{The multiplication computation is $O(\log y)$.} (or shifting if the base is 2).
+Signed integral exponentiation\index{exponentiation!signed integral} is performed with repeated multiplication (or shifting if the base is 2), but yields a floating result because $x^{-y}=1/x^y$.
+Hence, it is important to designate exponent integral-constants as unsigned or signed: ©3 \ 3u© return an integral result, while ©3 \ 3© returns a floating result.
+Floating exponentiation\index{exponentiation!floating} is performed using \Index{logarithm}s\index{exponentiation!logarithm}, so the base cannot be negative.
+\begin{cfa}
+sout | 2 ®\® 8u | 4 ®\® 3u | -4 ®\® 3u | 4 ®\® -3 | -4 ®\® -3 | 4.0 ®\® 2.1 | (1.0f+2.0fi) ®\® (3.0f+2.0fi) | endl;
+256 64 -64 0.015625 -0.015625 18.3791736799526 0.264715-1.1922i
+\end{cfa}
+Parenthesis are necessary for the complex constants or the expresion is parsed as ©1.0f+(2.0fi \ 3.0f)+2.0fi©.
+The exponentiation operator is available for all the basic types, but for user-defined types, only the integral-computation versions are available.
+For returning an integral value, the user type ©T© must define multiplication, ©*©, and one, ©1©;
+for returning a floating value, an additional divide of type ©T© into a ©double© returning a ©double© (©double ?/?( double, T )©) is necessary for negative exponents.
+
+
+\section{\texorpdfstring{Labelled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labelled continue / break}}
 
 While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
 Unfortunately, this restriction forces programmers to use \Indexc{goto} to achieve the equivalent control-flow for more than one level of nesting.
-To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@©continue©!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@©break©!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85}, as in Java.
+To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@\lstinline@continue@!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@\lstinline@break@!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85}, as in Java.
 For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
 for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement.
@@ -1130 +613 @@
 \end{figure}
 
-Both labelled ©continue© and ©break© are a ©goto©\index{goto@©goto©!restricted} restricted in the following ways:
+Both labelled ©continue© and ©break© are a ©goto©\index{goto@\lstinline@goto@!restricted} restricted in the following ways:
 \begin{itemize}
 \item
@@ -1143 +626 @@
 With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
 Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
-Otherwise, the implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
-
-
-%\section{\texorpdfstring{\protect\lstinline@with@ Statement}{with Statement}}
-\section{\texorpdfstring{\LstKeywordStyle{with} Statement}{with Statement}}
+The implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
+
+
+\section{\texorpdfstring{\protect\lstinline@switch@ Statement}{switch Statement}}
+
+C allows a number of questionable forms for the ©switch© statement:
+\begin{enumerate}
+\item
+By default, the end of a ©case© clause\footnote{
+In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
+\emph{falls through} to the next ©case© clause in the ©switch© statement;
+to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
+\begin{cfa}
+switch ( i ) {
+  case 1:
+        ...
+        // fall-through
+  case 2:
+        ...
+        break;  // exit switch statement
+}
+\end{cfa}
+The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\begin{cfa}
+switch ( argc ) {
+  case 3:
+        // open output file
+        // fall-through
+  case 2:
+        // open input file
+        break;  // exit switch statement
+  default:
+        // usage message
+}
+\end{cfa}
+&
+\begin{cfa}
+
+if ( argc == 3 ) {
+        // open output file
+        ®// open input file
+®} else if ( argc == 2 ) {
+        ®// open input file (duplicate)
+
+®} else {
+        // usage message
+}
+\end{cfa}
+\end{tabular}
+\end{cquote}
+In this example, case 2 is always done if case 3 is done.
+This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
+C also uses fall-through to handle multiple case-values resulting in the same action:
+\begin{cfa}
+switch ( i ) {
+  ®case 1: case 3: case 5:®     // odd values
+        // odd action
+        break;
+  ®case 2: case 4: case 6:®     // even values
+        // even action
+        break;
+}
+\end{cfa}
+However, this situation is handled in other languages without fall-through by allowing a list of case values.
+While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
+Hence, default fall-through semantics results in a large number of programming errors as programmers often \emph{forget} the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
+
+\item
+It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
+\begin{cfa}
+switch ( i ) {
+  case 0:
+        if ( j < k ) {
+                ...
+          ®case 1:®             // transfer into "if" statement
+                ...
+        } // if
+  case 2:
+        while ( j < 5 ) {
+                ...
+          ®case 3:®             // transfer into "while" statement
+                ...
+        } // while
+} // switch
+\end{cfa}
+The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
+The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
+The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
+There are no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
+Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
+\begin{cfa}
+register int n = (count + 7) / 8;
+switch ( count % 8 ) {
+case 0: do{ *to = *from++;
+case 7:         *to = *from++;
+case 6:         *to = *from++;
+case 5:         *to = *from++;
+case 4:         *to = *from++;
+case 3:         *to = *from++;
+case 2:         *to = *from++;
+case 1:         *to = *from++;
+                } while ( --n > 0 );
+}
+\end{cfa}
+which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
+While efficient, this sort of special purpose usage is questionable:
+\begin{quote}
+Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
+discovery.~\cite{Duff83}
+\end{quote}
+\item
+It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
+Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
+The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
+hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
+This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
+
+\item
+It is possible to place unreachable code at the start of a ©switch© statement, as in:
+\begin{cfa}
+switch ( x ) {
+        ®int y = 1;®                            §\C{// unreachable initialization}§
+        ®x = 7;®                                        §\C{// unreachable code without label/branch}§
+  case 0: ...
+        ...
+        ®int z = 0;®                            §\C{// unreachable initialization, cannot appear after case}§
+        z = 2;
+  case 1:
+        ®x = z;®                                        §\C{// without fall through, z is uninitialized}§
+}
+\end{cfa}
+While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
+Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
+As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
+The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
+\end{enumerate}
+
+Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
+\begin{itemize}
+\item
+the number of ©switch© statements is small,
+\item
+most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
+\item
+the ©default© clause is usually written as the last case-clause,
+\item
+and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
+\end{itemize}
+These observations put into perspective the \CFA changes to the ©switch©.
+\begin{enumerate}
+\item
+Eliminating default fall-through has the greatest potential for affecting existing code.
+However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
+\begin{cfa}
+case 1:  case 2:  case 3: ...
+\end{cfa}
+still works.
+Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
+Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, \eg:
+\begin{cfa}
+®choose® ( i ) {
+  case 1:  case 2:  case 3:
+        ...
+        ®// implicit end of switch (break)
+  ®case 5:
+        ...
+        ®fallthru®;                                     §\C{// explicit fall through}§
+  case 7:
+        ...
+        ®break®                                         §\C{// explicit end of switch (redundant)}§
+  default:
+        j = 3;
+}
+\end{cfa}
+Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
+An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
+An explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
+As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
+\item
+\Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
+Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
+\item
+The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end.
+Therefore, no change is made for this issue.
+\item
+Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{
+Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
+Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
+\begin{cfa}
+switch ( x ) {
+        ®int i = 0;®                            §\C{// allowed only at start}§
+  case 0:
+        ...
+        ®int j = 0;®                            §\C{// disallowed}§
+  case 1:
+        {
+                ®int k = 0;®                    §\C{// allowed at different nesting levels}§
+                ...
+          ®case 2:®                                     §\C{// disallow case in nested statements}§
+        }
+  ...
+}
+\end{cfa}
+\end{enumerate}
+
+
+\section{\texorpdfstring{\protect\lstinline@case@ Clause}{case Clause}}
+
+C restricts the ©case© clause of a ©switch© statement to a single value.
+For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
+Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
+Therefore, the ©case© clause is extended with a list of values, as in:
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
+\begin{cfa}
+switch ( i ) {
+  case ®1, 3, 5®:
+        ...
+  case ®2, 4, 6®:
+        ...
+}
+\end{cfa}
+&
+\begin{cfa}
+switch ( i ) {
+  case 1: case 3 : case 5:
+        ...
+  case 2: case 4 : case 6:
+        ...
+}
+\end{cfa}
+&
+\begin{cfa}
+
+// odd values
+
+// even values
+
+
+\end{cfa}
+\end{tabular}
+\end{cquote}
+In addition, subranges are allowed to specify case values.\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.}
+\begin{cfa}
+switch ( i ) {
+  case ®1~5:®                                   §\C{// 1, 2, 3, 4, 5}§
+        ...
+  case ®10~15:®                                 §\C{// 10, 11, 12, 13, 14, 15}§
+        ...
+}
+\end{cfa}
+Lists of subranges are also allowed.
+\begin{cfa}
+case ®1~5, 12~21, 35~42®:
+\end{cfa}
+
+
+\section{\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:
 \begin{cfa}
-struct S { §\C{// aggregate}§
-        char c; §\C{// fields}§
+struct S {                                                                      §\C{// aggregate}§
+        char c;                                                                 §\C{// fields}§
         int i;
         double d;
@@ -1162 +902 @@
 \begin{cfa}
 void f( S s ) {
-        ®s.®c; ®s.®i; ®s.®d; §\C{// access containing fields}§
+        `s.`c; `s.`i; `s.`d;                                    §\C{// access containing fields}§
 }
 \end{cfa}
@@ -1169 +909 @@
 \begin{C++}
 struct S {
-        char c; §\C{// fields}§
+        char c;                                                                 §\C{// fields}§
         int i;
         double d;
-        void f() { §\C{// implicit ``this'' aggregate}§
-                ®this->®c; ®this->®i; ®this->®d; §\C{// access containing fields}§
+        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/struct@ 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 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}§
-}
-\end{cfa}
-
-To simplify the programmer experience, \CFA provides a ©with© statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers.
+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}§
+}
+\end{cfa}
+
+To simplify the programmer experience, \CFA provides a @with@ statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers.
 Hence, the qualified fields become variables with the side-effect that it is easier to optimizing field references in a block.
 \begin{cfa}
-void f( S & this ) ®with ( this )® { §\C{// with statement}§
-        c; i; d; §\C{\color{red}// this.c, this.i, this.d}§
+void f( S & this ) `with ( this )` {            §\C{// with statement}§
+        c; i; d;                                                                §\C{\color{red}// this.c, this.i, this.d}§
 }
 \end{cfa}
 with the generality of opening multiple aggregate-parameters:
 \begin{cfa}
-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}§
-}
-\end{cfa}
-
-In detail, the ©with© statement has the form:
+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}§
+}
+\end{cfa}
+
+In detail, the @with@ statement has the form:
 \begin{cfa}
 §\emph{with-statement}§:
@@ -1217 +957 @@
 The difference between parallel and nesting occurs for fields with the same name and type:
 \begin{cfa}
-struct S { int ®i®; int j; double m; } s, w;
-struct T { int ®i®; int k; int m; } t, w;
+struct S { int `i`; int j; double m; } s, w;
+struct T { int `i`; int k; int m; } t, w;
 with ( s, t ) {
-        j + k; §\C{// unambiguous, s.j + t.k}§
-        m = 5.0; §\C{// unambiguous, t.m = 5.0}§
-        m = 1; §\C{// unambiguous, s.m = 1}§
-        int a = m; §\C{// unambiguous, a = s.i }§
-        double b = m; §\C{// unambiguous, b = t.m}§
-        int c = s.i + t.i; §\C{// unambiguous, qualification}§
-        (double)m; §\C{// unambiguous, cast}§
-}
-\end{cfa}
-For parallel semantics, both ©s.i© and ©t.i© are visible, so ©i© is ambiguous without qualification;
-for nested semantics, ©t.i© hides ©s.i©, so ©i© implies ©t.i©.
+        j + k;                                                                  §\C{// unambiguous, s.j + t.k}§
+        m = 5.0;                                                                §\C{// unambiguous, t.m = 5.0}§
+        m = 1;                                                                  §\C{// unambiguous, s.m = 1}§
+        int a = m;                                                              §\C{// unambiguous, a = s.i }§
+        double b = m;                                                   §\C{// unambiguous, b = t.m}§
+        int c = s.i + t.i;                                              §\C{// unambiguous, qualification}§
+        (double)m;                                                              §\C{// unambiguous, cast}§
+}
+\end{cfa}
+For parallel semantics, both @s.i@ and @t.i@ are visible, so @i@ is ambiguous without qualification;
+for nested semantics, @t.i@ hides @s.i@, so @i@ implies @t.i@.
 \CFA's ability to overload variables means fields with the same name but different types are automatically disambiguated, eliminating most qualification when opening multiple aggregates.
 Qualification or a cast is used to disambiguate.
 
-There is an interesting problem between parameters and the function-body ©with©, \eg:
-\begin{cfa}
-void ?{}( S & s, int i ) with ( s ) { §\C{// constructor}§
-        ®s.i = i;®  j = 3;  m = 5.5; §\C{// initialize fields}§
-}
-\end{cfa}
-Here, the assignment ©s.i = i© means ©s.i = s.i©, which is meaningless, and there is no mechanism to qualify the parameter ©i©, making the assignment impossible using the function-body ©with©.
+There is an interesting problem between parameters and the function-body @with@, \eg:
+\begin{cfa}
+void ?{}( S & s, int i ) with ( s ) {           §\C{// constructor}§
+        `s.i = i;`  j = 3;  m = 5.5;                    §\C{// initialize fields}§
+}
+\end{cfa}
+Here, the assignment @s.i = i@ means @s.i = s.i@, which is meaningless, and there is no mechanism to qualify the parameter @i@, making the assignment impossible using the function-body @with@.
 To solve this problem, parameters are treated like an initialized aggregate:
 \begin{cfa}
@@ -1250 +990 @@
 and implicitly opened \emph{after} a function-body open, to give them higher priority:
 \begin{cfa}
-void ?{}( S & s, int ®i® ) with ( s ) ®with( §\emph{\color{red}params}§ )® {
-        s.i = ®i®; j = 3; m = 5.5;
-}
-\end{cfa}
-Finally, a cast may be used to disambiguate among overload variables in a ©with© expression:
-\begin{cfa}
-with ( w ) { ... } §\C{// ambiguous, same name and no context}§
-with ( (S)w ) { ... } §\C{// unambiguous, cast}§
-\end{cfa}
-and ©with© expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
+void ?{}( S & s, int `i` ) with ( s ) `with( §\emph{\color{red}params}§ )` {
+        s.i = `i`; j = 3; m = 5.5;
+}
+\end{cfa}
+Finally, a cast may be used to disambiguate among overload variables in a @with@ expression:
+\begin{cfa}
+with ( w ) { ... }                                                      §\C{// ambiguous, same name and no context}§
+with ( (S)w ) { ... }                                           §\C{// unambiguous, cast}§
+\end{cfa}
+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{// 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}§
+%               i = 2; j = 3;                                           §\C{\color{red}// sr.i, sr.j}§
 %       }
-%       i = 1; j = 2; §\C{\color{red}// sv.i, sv.j}§
+%       i = 1; j = 2;                                                   §\C{\color{red}// sv.i, sv.j}§
 % }
 % \end{cfa}
@@ -1279 +1019 @@
 class C {
         int i, j;
-        int mem() { §\C{\color{red}// implicit "this" parameter}§
-                i = 1; §\C{\color{red}// this->i}§
-                j = 2; §\C{\color{red}// this->j}§
+        int mem() {                                     §\C{\color{red}// implicit "this" parameter}§
+                i = 1;                                  §\C{\color{red}// this->i}§
+                j = 2;                                  §\C{\color{red}// this->j}§
         }
 }
@@ -1288 +1028 @@
 \begin{cfa}
 struct S { int i, j; };
-int mem( S & ®this® ) { §\C{// explicit "this" parameter}§
-        ®this.®i = 1; §\C{// "this" is not elided}§
+int mem( S & ®this® ) {                 §\C{// explicit "this" parameter}§
+        ®this.®i = 1;                           §\C{// "this" is not elided}§
         ®this.®j = 2;
 }
@@ -1298 +1038 @@
 \begin{cfa}
 int mem( S & this ) ®with( this )® { §\C{// with clause}§
-        i = 1; §\C{\color{red}// this.i}§
-        j = 2; §\C{\color{red}// this.j}§
+        i = 1;                                          §\C{\color{red}// this.i}§
+        j = 2;                                          §\C{\color{red}// this.j}§
 }
 \end{cfa}
@@ -1316 +1056 @@
         struct S1 { ... } s1;
         struct S2 { ... } s2;
-        ®with( s1 )® { §\C{// with statement}§
+        ®with( s1 )® {                          §\C{// with statement}§
                 // access fields of s1 without qualification
-                ®with s2® { §\C{// nesting}§
+                ®with s2® {                             §\C{// nesting}§
                         // access fields of s1 and s2 without qualification
                 }
@@ -1373 +1113 @@
 Non-local transfer can cause stack unwinding, \ie non-local routine termination, depending on the kind of raise.
 \begin{cfa}
-exception_t E {}; §\C{// exception type}§
+exception_t E {};                               §\C{// exception type}§
 void f(...) {
-        ... throw E{}; ... §\C{// termination}§
-        ... throwResume E{}; ... §\C{// resumption}§
+        ... throw E{}; ...                      §\C{// termination}§
+        ... throwResume E{}; ...        §\C{// resumption}§
 }
 try {
         f(...);
-} catch( E e ; §boolean-predicate§ ) {          §\C[8cm]{// termination handler}§
+} catch( E e ; §boolean-predicate§ ) {                  §\C[8cm]{// termination handler}§
         // recover and continue
-} catchResume( E e ; §boolean-predicate§ ) { §\C{// resumption handler}\CRT§
+} catchResume( E e ; §boolean-predicate§ ) {    §\C{// resumption handler}\CRT§
         // repair and return
 } finally {
@@ -1442 +1182 @@
 For example, a routine returning a \Index{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 \Index{onion}).
-While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice, even though Dennis Richie believed otherwise:
-\begin{quote}
-In spite of its difficulties, I believe that the C's approach to declarations remains plausible, and am comfortable with it; it is a useful unifying principle.~\cite[p.~12]{Ritchie93}
-\end{quote}
+While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice.
 
 \CFA provides its own type, variable and routine declarations, using a different syntax.
@@ -1635 +1372 @@
 *x = 3;                 // implicit dereference
 int * ®const® y = (int *)104;
-*y = *x;                        // implicit dereference
+*y = *x;                // implicit dereference
 \end{cfa}
 \end{tabular}
@@ -1649 +1386 @@
 \hline
 \begin{cfa}
-lda             r1,100   // load address of x
-ld               r2,(r1)   // load value of x
-lda             r3,104   // load address of y
-st               r2,(r3)   // store x into y
+lda             r1,100  // load address of x
+ld               r2,(r1)          // load value of x
+lda             r3,104  // load address of y
+st               r2,(r3)          // store x into y
 \end{cfa}
 &
 \begin{cfa}
 
-ld              r2,(100)   // load value of x
-
-st              r2,(104)   // store x into y
+ld              r2,(100)        // load value of x
+
+st              r2,(104)        // store x into y
 \end{cfa}
 \end{tabular}
@@ -1673 +1410 @@
 \begin{cfa}
 int x, y, ®*® p1, ®*® p2, ®**® p3;
-p1 = ®&®x;     // p1 points to x
-p2 = p1;     // p2 points to x
-p1 = ®&®y;     // p1 points to y
-p3 = &p2;  // p3 points to p2
+p1 = ®&®x;               // p1 points to x
+p2 = p1;                 // p2 points to x
+p1 = ®&®y;               // p1 points to y
+p3 = &p2;               // p3 points to p2
 \end{cfa}
 &
@@ -1687 +1424 @@
 For example, \Index*{Algol68}~\cite{Algol68} infers pointer dereferencing to select the best meaning for each pointer usage
 \begin{cfa}
-p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§
+p2 = p1 + x;                                    §\C{// compiler infers *p2 = *p1 + x;}§
 \end{cfa}
 Algol68 infers the following dereferencing ©*p2 = *p1 + x©, because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
-Unfortunately, automatic dereferencing does not work in all cases, and so some mechanism is necessary to fix incorrect choices.
+Unfortunately, automatic dereferencing does not work in all cases, and so some mechanism is necessary to fix incorrect choices. 
 
 Rather than inferring dereference, most programming languages pick one implicit dereferencing semantics, and the programmer explicitly indicates the other to resolve address-duality.
 In C, objects of pointer type always manipulate the pointer object's address:
 \begin{cfa}
-p1 = p2; §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§
-p2 = p1 + x; §\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}§
+p1 = p2;                                                §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§
+p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}§
 \end{cfa}
 even though the assignment to ©p2© is likely incorrect, and the programmer probably meant:
 \begin{cfa}
-p1 = p2; §\C{// pointer address assignment}§
-®*®p2 = ®*®p1 + x; §\C{// pointed-to value assignment / operation}§
+p1 = p2;                                                §\C{// pointer address assignment}§
+®*®p2 = ®*®p1 + x;                              §\C{// pointed-to value assignment / operation}§
 \end{cfa}
 The C semantics work well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
@@ -1718 +1455 @@
 \begin{cfa}
 int x, y, ®&® r1, ®&® r2, ®&&® r3;
-®&®r1 = &x; §\C{// r1 points to x}§
-®&®r2 = &r1; §\C{// r2 points to x}§
-®&®r1 = &y; §\C{// r1 points to y}§
-®&&®r3 = ®&®&r2; §\C{// r3 points to r2}§
+®&®r1 = &x;                                             §\C{// r1 points to x}§
+®&®r2 = &r1;                                    §\C{// r2 points to x}§
+®&®r1 = &y;                                             §\C{// r1 points to y}§
+®&&®r3 = ®&®&r2;                                §\C{// r3 points to r2}§
 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§
 \end{cfa}
@@ -1737 +1474 @@
 For a \CFA reference type, the cancellation on the left-hand side of assignment leaves the reference as an address (\Index{lvalue}):
 \begin{cfa}
-(&®*®)r1 = &x; §\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}§
+(&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}§
 \end{cfa}
 Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
 \begin{cfa}
-(&(&®*®)®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}§
+(&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}§
 \end{cfa}
 Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth.
@@ -1749 +1486 @@
 int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
                  &r1 = x,    &&r2 = r1,   &&&r3 = r2;
-***p3 = 3; §\C{// change x}§
-r3 = 3; §\C{// change x, ***r3}§
-**p3 = ...; §\C{// change p1}§
-&r3 = ...; §\C{// change r1, (\&*)**r3, 1 cancellation}§
-*p3 = ...; §\C{// change p2}§
-&&r3 = ...; §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§
-&&&r3 = p3; §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
+***p3 = 3;                                              §\C{// change x}§
+r3 = 3;                                                 §\C{// change x, ***r3}§
+**p3 = ...;                                             §\C{// change p1}§
+&r3 = ...;                                              §\C{// change r1, (\&*)**r3, 1 cancellation}§
+*p3 = ...;                                              §\C{// change p2}§
+&&r3 = ...;                                             §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§
+&&&r3 = p3;                                             §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
 \end{cfa}
 Furthermore, both types are equally performant, as the same amount of dereferencing occurs for both types.
@@ -1762 +1499 @@
 As for a pointer type, a reference type may have qualifiers:
 \begin{cfa}
-const int cx = 5; §\C{// cannot change cx;}§
-const int & cr = cx; §\C{// cannot change what cr points to}§
-®&®cr = &cx; §\C{// can change cr}§
-cr = 7; §\C{// error, cannot change cx}§
-int & const rc = x; §\C{// must be initialized}§
-®&®rc = &x; §\C{// error, cannot change rc}§
-const int & const crc = cx; §\C{// must be initialized}§
-crc = 7; §\C{// error, cannot change cx}§
-®&®crc = &cx; §\C{// error, cannot change crc}§
+const int cx = 5;                                       §\C{// cannot change cx;}§
+const int & cr = cx;                            §\C{// cannot change what cr points to}§
+®&®cr = &cx;                                            §\C{// can change cr}§
+cr = 7;                                                         §\C{// error, cannot change cx}§
+int & const rc = x;                                     §\C{// must be initialized}§
+®&®rc = &x;                                                     §\C{// error, cannot change rc}§
+const int & const crc = cx;                     §\C{// must be initialized}§
+crc = 7;                                                        §\C{// error, cannot change cx}§
+®&®crc = &cx;                                           §\C{// error, cannot change crc}§
 \end{cfa}
 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced\index{coercion} into the reference}:
 \begin{cfa}
-int & const cr = *0; §\C{// where 0 is the int * zero}§
+int & const cr = *0;                            §\C{// where 0 is the int * zero}§
 \end{cfa}
 Note, constant reference-types do not prevent \Index{addressing errors} because of explicit storage-management:
@@ -1781 +1518 @@
 cr = 5;
 free( &cr );
-cr = 7; §\C{// unsound pointer dereference}§
+cr = 7;                                                         §\C{// unsound pointer dereference}§
 \end{cfa}
 
@@ -1806 +1543 @@
 \begin{cfa}
 int w, x, y, z, & ar[3] = { x, y, z }; §\C{// initialize array of references}§
-&ar[1] = &w; §\C{// change reference array element}§
-typeof( ar[1] ) p; §\C{// (gcc) is int, \ie the type of referenced object}§
-typeof( &ar[1] ) q; §\C{// (gcc) is int \&, \ie the type of reference}§
-sizeof( ar[1] ) == sizeof( int ); §\C{// is true, \ie the size of referenced object}§
-sizeof( &ar[1] ) == sizeof( int *) §\C{// is true, \ie the size of a reference}§
+&ar[1] = &w;                                            §\C{// change reference array element}§
+typeof( ar[1] ) p;                                      §\C{// (gcc) is int, \ie the type of referenced object}§
+typeof( &ar[1] ) q;                                     §\C{// (gcc) is int \&, \ie the type of reference}§
+sizeof( ar[1] ) == sizeof( int );       §\C{// is true, \ie the size of referenced object}§
+sizeof( &ar[1] ) == sizeof( int *)      §\C{// is true, \ie the size of a reference}§
 \end{cfa}
 
@@ -1827 +1564 @@
 Therefore, for pointer/reference initialization, the initializing value must be an address not a value.
 \begin{cfa}
-int * p = &x; §\C{// assign address of x}§
-®int * p = x;® §\C{// assign value of x}§
-int & r = x; §\C{// must have address of x}§
+int * p = &x;                                           §\C{// assign address of x}§
+®int * p = x;®                                          §\C{// assign value of x}§
+int & r = x;                                            §\C{// must have address of x}§
 \end{cfa}
 Like the previous example with C pointer-arithmetic, it is unlikely assigning the value of ©x© into a pointer is meaningful (again, a warning is usually given).
@@ -1838 +1575 @@
 Similarly, when a reference type is used for a parameter/return type, the call-site argument does not require a reference operator for the same reason.
 \begin{cfa}
-int & f( int & r ); §\C{// reference parameter and return}§
-z = f( x ) + f( y ); §\C{// reference operator added, temporaries needed for call results}§
+int & f( int & r );                                     §\C{// reference parameter and return}§
+z = f( x ) + f( y );                            §\C{// reference operator added, temporaries needed for call results}§
 \end{cfa}
 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©r© can be locally reassigned within ©f©.
@@ -1866 +1603 @@
 void f( int & r );
 void g( int * p );
-f( 3 );                   g( ®&®3 ); §\C{// compiler implicit generates temporaries}§
-f( x + y );             g( ®&®(x + y) ); §\C{// compiler implicit generates temporaries}§
+f( 3 );                   g( ®&®3 );            §\C{// compiler implicit generates temporaries}§
+f( x + y );             g( ®&®(x + y) );        §\C{// compiler implicit generates temporaries}§
 \end{cfa}
 Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
@@ -1878 +1615 @@
 \begin{cfa}
 void f( int i );
-void (* fp)( int ); §\C{// routine pointer}§
-fp = f; §\C{// reference initialization}§
-fp = &f; §\C{// pointer initialization}§
-fp = *f; §\C{// reference initialization}§
-fp(3); §\C{// reference invocation}§
-(*fp)(3); §\C{// pointer invocation}§
+void (* fp)( int );                                     §\C{// routine pointer}§
+fp = f;                                                         §\C{// reference initialization}§
+fp = &f;                                                        §\C{// pointer initialization}§
+fp = *f;                                                        §\C{// reference initialization}§
+fp(3);                                                          §\C{// reference invocation}§
+(*fp)(3);                                                       §\C{// pointer invocation}§
 \end{cfa}
 While C's treatment of routine objects has similarity to inferring a reference type in initialization contexts, the examples are assignment not initialization, and all possible forms of assignment are possible (©f©, ©&f©, ©*f©) without regard for type.
 Instead, a routine object should be referenced by a ©const© reference:
 \begin{cfa}
-®const® void (®&® fr)( int ) = f; §\C{// routine reference}§
-fr = ... §\C{// error, cannot change code}§
-&fr = ...; §\C{// changing routine reference}§
-fr( 3 ); §\C{// reference call to f}§
-(*fr)(3); §\C{// error, incorrect type}§
+®const® void (®&® fr)( int ) = f;       §\C{// routine reference}§
+fr = ...                                                        §\C{// error, cannot change code}§
+&fr = ...;                                                      §\C{// changing routine reference}§
+fr( 3 );                                                        §\C{// reference call to f}§
+(*fr)(3);                                                       §\C{// error, incorrect type}§
 \end{cfa}
 because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
@@ -1905 +1642 @@
 \begin{itemize}
 \item
-if ©R© is an \Index{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).
-
-\item
-if ©L© is an \Index{lvalue} of type ©T &©$_1\cdots$ ©&©$_l$, where $l \ge 0$ references (©&© symbols), than ©&L© has type ©T ®*®&©$_{\color{red}1}\cdots$ ©&©$_{\color{red}l}$, \ie ©T© pointer with $l$ references (©&© symbols).
+if ©R© is an \Index{rvalue} of type ©T &$_1$...&$_r$© where $r \ge 1$ references (©&© symbols) then ©&R© has type ©T ®*®&$_{\color{red}2}$...&$_{\color{red}r}$©, \ie ©T© pointer with $r-1$ references (©&© symbols).
+
+\item
+if ©L© is an \Index{lvalue} of type ©T &$_1$...&$_l$© where $l \ge 0$ references (©&© symbols) then ©&L© has type ©T ®*®&$_{\color{red}1}$...&$_{\color{red}l}$©, \ie ©T© pointer with $l$ references (©&© symbols).
 \end{itemize}
 The following example shows the first rule applied to different \Index{rvalue} contexts:
@@ -1914 +1651 @@
 int x, * px, ** ppx, *** pppx, **** ppppx;
 int & rx = x, && rrx = rx, &&& rrrx = rrx ;
-x = rrrx; §\C[2.0in]{// rrrx is an lvalue with type int \&\&\& (equivalent to x)}§
-px = &rrrx; §\C{// starting from rrrx, \&rrrx is an rvalue with type int *\&\&\& (\&x)}§
-ppx = &&rrrx; §\C{// starting from \&rrrx, \&\&rrrx is an rvalue with type int **\&\& (\&rx)}§
-pppx = &&&rrrx; §\C{// starting from \&\&rrrx, \&\&\&rrrx is an rvalue with type int ***\& (\&rrx)}§
-ppppx = &&&&rrrx; §\C{// starting from \&\&\&rrrx, \&\&\&\&rrrx is an rvalue with type int **** (\&rrrx)}§
+x = rrrx;               // rrrx is an lvalue with type int &&& (equivalent to x)
+px = &rrrx;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (&x)
+ppx = &&rrrx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (&rx)
+pppx = &&&rrrx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (&rrx)
+ppppx = &&&&rrrx; // starting from &&&rrrx, &&&&rrrx is an rvalue with type int **** (&rrrx)
 \end{cfa}
 The following example shows the second rule applied to different \Index{lvalue} contexts:
@@ -1924 +1661 @@
 int x, * px, ** ppx, *** pppx;
 int & rx = x, && rrx = rx, &&& rrrx = rrx ;
-rrrx = 2; §\C{// rrrx is an lvalue with type int \&\&\& (equivalent to x)}§
-&rrrx = px; §\C{// starting from rrrx, \&rrrx is an rvalue with type int *\&\&\& (rx)}§
-&&rrrx = ppx; §\C{// starting from \&rrrx, \&\&rrrx is an rvalue with type int **\&\& (rrx)}§
-&&&rrrx = pppx; §\C{// starting from \&\&rrrx, \&\&\&rrrx is an rvalue with type int ***\& (rrrx)}\CRT§
+rrrx = 2;               // rrrx is an lvalue with type int &&& (equivalent to x)
+&rrrx = px;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (rx)
+&&rrrx = ppx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (rrx)
+&&&rrrx = pppx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (rrrx)
 \end{cfa}
 
@@ -1940 +1677 @@
 \begin{cfa}
 int x;
-x + 1; §\C[2.0in]{// lvalue variable (int) converts to rvalue for expression}§
+x + 1;                  // lvalue variable (int) converts to rvalue for expression
 \end{cfa}
 An rvalue has no type qualifiers (©cv©), so the lvalue qualifiers are dropped.
@@ -1950 +1687 @@
 \begin{cfa}
 int x, &r = x, f( int p );
-x = ®r® + f( ®r® ); §\C{// lvalue reference converts to rvalue}§
+x = ®r® + f( ®r® );  // lvalue reference converts to rvalue
 \end{cfa}
 An rvalue has no type qualifiers (©cv©), so the reference qualifiers are dropped.
@@ -1957 +1694 @@
 lvalue to reference conversion: \lstinline[deletekeywords=lvalue]@lvalue-type cv1 T@ converts to ©cv2 T &©, which allows implicitly converting variables to references.
 \begin{cfa}
-int x, &r = ®x®, f( int & p ); §\C{// lvalue variable (int) convert to reference (int \&)}§
-f( ®x® ); §\C{// lvalue variable (int) convert to reference (int \&)}§
+int x, &r = ®x®, f( int & p ); // lvalue variable (int) convert to reference (int &)
+f( ®x® );               // lvalue variable (int) convert to reference (int &)
 \end{cfa}
 Conversion can restrict a type, where ©cv1© $\le$ ©cv2©, \eg passing an ©int© to a ©const volatile int &©, which has low cost.
@@ -1968 +1705 @@
 \begin{cfa}
 int x, & f( int & p );
-f( ®x + 3® );   §\C[1.5in]{// rvalue parameter (int) implicitly converts to lvalue temporary reference (int \&)}§
-®&f®(...) = &x; §\C{// rvalue result (int \&) implicitly converts to lvalue temporary reference (int \&)}\CRT§
+f( ®x + 3® );   // rvalue parameter (int) implicitly converts to lvalue temporary reference (int &)
+®&f®(...) = &x; // rvalue result (int &) implicitly converts to lvalue temporary reference (int &)
 \end{cfa}
 In both case, modifications to the temporary are inaccessible (\Index{warning}).
@@ -2158 +1895 @@
 in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
 \begin{cfa}
-[§\,§] g(); §\C{// no input or output parameters}§
-[ void ] g( void ); §\C{// no input or output parameters}§
+[§\,§] g();                                                     §\C{// no input or output parameters}§
+[ void ] g( void );                                     §\C{// no input or output parameters}§
 \end{cfa}
 
@@ -2177 +1914 @@
 \begin{cfa}
 typedef int foo;
-int f( int (* foo) ); §\C{// foo is redefined as a parameter name}§
+int f( int (* foo) );                           §\C{// foo is redefined as a parameter name}§
 \end{cfa}
 The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
@@ -2185 +1922 @@
 C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
 \begin{cfa}
-[ int ] f( * int, int * ); §\C{// returns an integer, accepts 2 pointers to integers}§
-[ * int, int * ] f( int ); §\C{// returns 2 pointers to integers, accepts an integer}§
+[ int ] f( * int, int * );                      §\C{// returns an integer, accepts 2 pointers to integers}§
+[ * int, int * ] f( int );                      §\C{// returns 2 pointers to integers, accepts an integer}§
 \end{cfa}
 The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in:
 \begin{cfa}
 #define ptoa( n, d ) int (*n)[ d ]
-int f( ptoa( p, 5 ) ) ... §\C{// expands to int f( int (*p)[ 5 ] )}§
-[ int ] f( ptoa( p, 5 ) ) ... §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
+int f( ptoa( p, 5 ) ) ...                       §\C{// expands to int f( int (*p)[ 5 ] )}§
+[ int ] f( ptoa( p, 5 ) ) ...           §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
 \end{cfa}
 Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
@@ -2214 +1951 @@
         int z;
         ... x = 0; ... y = z; ...
-        ®return;® §\C{// implicitly return x, y}§
+        ®return;®                                                       §\C{// implicitly return x, y}§
 }
 \end{cfa}
@@ -2224 +1961 @@
 [ int x, int y ] f() {
         ...
-} §\C{// implicitly return x, y}§
+}                                                                               §\C{// implicitly return x, y}§
 \end{cfa}
 In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
@@ -2233 +1970 @@
 [ int x, int y ] f( int, x, int y ) {
         ...
-} §\C{// implicitly return x, y}§
+}                                                                               §\C{// implicitly return x, y}§
 \end{cfa}
 This notation allows the compiler to eliminate temporary variables in nested routine calls.
 \begin{cfa}
-[ int x, int y ] f( int, x, int y ); §\C{// prototype declaration}§
+[ int x, int y ] f( int, x, int y );    §\C{// prototype declaration}§
 int a, b;
 [a, b] = f( f( f( a, b ) ) );
@@ -2251 +1988 @@
 as well, parameter names are optional, \eg:
 \begin{cfa}
-[ int x ] f (); §\C{// returning int with no parameters}§
-[ * int ] g (int y); §\C{// returning pointer to int with int parameter}§
-[ ] 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 ();                                                 §\C{// returning int with no parameters}§
+[ * int ] g (int y);                                    §\C{// returning pointer to int with int parameter}§
+[ ] 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).
@@ -2275 +2012 @@
 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}
 While parameter names are optional, \emph{a routine name cannot be specified};
 for example, the following is incorrect:
 \begin{cfa}
-* [ int x ] f () fp; §\C{// routine name "f" is not allowed}§
+* [ int x ] f () fp;                                    §\C{// routine name "f" is not allowed}§
 \end{cfa}
 
@@ -2306 +2043 @@
 whereas a named (keyword) call may be:
 \begin{cfa}
-p( z : 3, x : 4, y : 7 );  §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§
+p( z : 3, x : 4, y : 7 );       §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§
 \end{cfa}
 Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters.
@@ -2323 +2060 @@
 For example, the following routine prototypes and definition are all valid.
 \begin{cfa}
-void p( int, int, int ); §\C{// equivalent prototypes}§
+void p( int, int, int );                        §\C{// equivalent prototypes}§
 void p( int x, int y, int z );
 void p( int y, int x, int z );
 void p( int z, int y, int x );
-void p( int q, int r, int s ) {} §\C{// match with this definition}§
+void p( int q, int r, int s ) {}        §\C{// match with this definition}§
 \end{cfa}
 Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming.
@@ -2339 +2076 @@
 int f( int x, double y );
 
-f( j : 3, i : 4 ); §\C{// 1st f}§
-f( x : 7, y : 8.1 ); §\C{// 2nd f}§
-f( 4, 5 );  §\C{// ambiguous call}§
+f( j : 3, i : 4 );                              §\C{// 1st f}§
+f( x : 7, y : 8.1 );                    §\C{// 2nd f}§
+f( 4, 5 );                                              §\C{// ambiguous call}§
 \end{cfa}
 However, named arguments compound routine resolution in conjunction with conversions:
 \begin{cfa}
-f( i : 3, 5.7 ); §\C{// ambiguous call ?}§
+f( i : 3, 5.7 );                                §\C{// ambiguous call ?}§
 \end{cfa}
 Depending on the cost associated with named arguments, this call could be resolvable or ambiguous.
@@ -2359 +2096 @@
 the allowable positional calls are:
 \begin{cfa}
-p(); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
-p( 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
-p( 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
-p( 4, 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§
+p();                                                    §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
+p( 4 );                                                 §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
+p( 4, 4 );                                              §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
+p( 4, 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§
 // empty arguments
-p(  , 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§
-p( 4,  , 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§
-p( 4, 4,   ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
-p( 4,  ,   ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
-p(  , 4,   ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§
-p(  ,  , 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
-p(  ,  ,   ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
+p(  , 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§
+p( 4,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§
+p( 4, 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
+p( 4,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
+p(  , 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§
+p(  ,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
+p(  ,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
 \end{cfa}
 Here the missing arguments are inserted from the default values in the parameter list.
@@ -2394 +2131 @@
 Default values may only appear in a prototype versus definition context:
 \begin{cfa}
-void p( int x, int y = 2, int z = 3 ); §\C{// prototype: allowed}§
-void p( int, int = 2, int = 3 ); §\C{// prototype: allowed}§
-void p( int x, int y = 2, int z = 3 ) {} §\C{// definition: not allowed}§
+void p( int x, int y = 2, int z = 3 );          §\C{// prototype: allowed}§
+void p( int, int = 2, int = 3 );                        §\C{// prototype: allowed}§
+void p( int x, int y = 2, int z = 3 ) {}        §\C{// definition: not allowed}§
 \end{cfa}
 The reason for this restriction is to allow separate compilation.
@@ -2421 +2158 @@
 \begin{cfa}
 void p( int x, int y = 2, int z = 3... );
-p( 1, 4, 5, 6, z : 3 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
-p( 1, z : 3, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
+p( 1, 4, 5, 6, z : 3 );         §\C{// assume p( /* positional */, ... , /* named */ );}§
+p( 1, z : 3, 4, 5, 6 );         §\C{// assume p( /* positional */, /* named */, ... );}§
 \end{cfa}
 The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
@@ -2452 +2189 @@
 Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as:
 \begin{cfa}
-p( 1, /* default */, 5 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§
+p( 1, /* default */, 5 );               §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§
 \end{cfa}
 
@@ -2465 +2202 @@
 \begin{cfa}
 struct {
-        int f1; §\C{// named field}§
-        int f2 : 4; §\C{// named field with bit field size}§
-        int : 3; §\C{// unnamed field for basic type with bit field size}§
-        int ; §\C{// disallowed, unnamed field}§
-        int *; §\C{// disallowed, unnamed field}§
-        int (*)( int ); §\C{// disallowed, unnamed field}§
+        int f1;                                 §\C{// named field}§
+        int f2 : 4;                             §\C{// named field with bit field size}§
+        int : 3;                                §\C{// unnamed field for basic type with bit field size}§
+        int ;                                   §\C{// disallowed, unnamed field}§
+        int *;                                  §\C{// disallowed, unnamed field}§
+        int (*)( int );                 §\C{// disallowed, unnamed field}§
 };
 \end{cfa}
@@ -2478 +2215 @@
 \begin{cfa}
 struct {
-        int , , ; §\C{// 3 unnamed fields}§
+        int , , ;                               §\C{// 3 unnamed fields}§
 }
 \end{cfa}
@@ -2525 +2262 @@
         struct T t;
 } s;
-
+        
 
 
@@ -2572 +2309 @@
 const unsigned int size = 5;
 int ia[size];
-... §\C{// assign values to array ia}§
-qsort( ia, size ); §\C{// sort ascending order using builtin ?<?}§
+...                                             §\C{// assign values to array ia}§
+qsort( ia, size );              §\C{// sort ascending order using builtin ?<?}§
 {
         ®int ?<?( int x, int y ) { return x > y; }® §\C{// nested routine}§
-        qsort( ia, size ); §\C{// sort descending order by local redefinition}§
+        qsort( ia, size );      §\C{// sort descending order by local redefinition}§
 }
 \end{cfa}
@@ -2584 +2321 @@
 The following program in undefined in \CFA (and Indexc{gcc})
 \begin{cfa}
-[* [int]( int )] foo() { §\C{// int (* foo())( int )}§
+[* [int]( int )] foo() {                §\C{// int (* foo())( int )}§
         int ®i® = 7;
         int bar( int p ) {
-                ®i® += 1; §\C{// dependent on local variable}§
-                sout | ®i®;
+                ®i® += 1;                               §\C{// dependent on local variable}§
+                sout | ®i® | endl;
         }
-        return bar; §\C{// undefined because of local dependence}§
+        return bar;                                     §\C{// undefined because of local dependence}§
 }
 int main() {
-        * [int]( int ) fp = foo(); §\C{// int (* fp)( int )}§
-        sout | fp( 3 );
-}
-\end{cfa}
-because
+        * [int]( int ) fp = foo();      §\C{// int (* fp)( int )}§
+        sout | fp( 3 ) | endl;
+}
+\end{cfa}
+because 
 
 Currently, there are no \Index{lambda} expressions, \ie unnamed routines because routine names are very important to properly select the correct routine.
@@ -2606 +2343 @@
 In C and \CFA, lists of elements appear in several contexts, such as the parameter list of a routine call.
 \begin{cfa}
-f( ®2, x, 3 + i® ); §\C{// element list}§
+f( ®2, x, 3 + i® );                             §\C{// element list}§
 \end{cfa}
 A list of elements is called a \newterm{tuple}, and is different from a \Index{comma expression}.
@@ -2623 +2360 @@
 typedef struct { int quot, rem; } div_t;        §\C[7cm]{// from include stdlib.h}§
 div_t div( int num, int den );
-div_t qr = div( 13, 5 ); §\C{// return quotient/remainder aggregate}§
-printf( "%d %d\n", qr.quot, qr.rem ); §\C{// print quotient/remainder}§
+div_t qr = div( 13, 5 );                                        §\C{// return quotient/remainder aggregate}§
+printf( "%d %d\n", qr.quot, qr.rem );           §\C{// print quotient/remainder}§
 \end{cfa}
 This approach requires a name for the return type and fields, where \Index{naming} is a common programming-language issue.
@@ -2634 +2371 @@
 For example, consider C's \Indexc{modf} function, which returns the integral and fractional part of a floating value.
 \begin{cfa}
-double modf( double x, double * i ); §\C{// from include math.h}§
-double intp, frac = modf( 13.5, &intp ); §\C{// return integral and fractional components}§
-printf( "%g %g\n", intp, frac ); §\C{// print integral/fractional components}§
+double modf( double x, double * i );            §\C{// from include math.h}§
+double intp, frac = modf( 13.5, &intp );        §\C{// return integral and fractional components}§
+printf( "%g %g\n", intp, frac );                        §\C{// print integral/fractional components}§
 \end{cfa}
 This approach requires allocating storage for the return values, which complicates the call site with a sequence of variable declarations leading to the call.
@@ -2663 +2400 @@
 When a function call is passed as an argument to another call, the best match of actual arguments to formal parameters is evaluated given all possible expression interpretations in the current scope.
 \begin{cfa}
-void g( int, int ); §\C{// 1}§
-void g( double, double ); §\C{// 2}§
-g( div( 13, 5 ) ); §\C{// select 1}§
-g( modf( 13.5 ) ); §\C{// select 2}§
+void g( int, int );                                                     §\C{// 1}§
+void g( double, double );                                       §\C{// 2}§
+g( div( 13, 5 ) );                                                      §\C{// select 1}§
+g( modf( 13.5 ) );                                                      §\C{// select 2}§
 \end{cfa}
 In this case, there are two overloaded ©g© routines.
@@ -2675 +2412 @@
 The previous examples can be rewritten passing the multiple returned-values directly to the ©printf© function call.
 \begin{cfa}
-[ int, int ] div( int x, int y ); §\C{// from include stdlib}§
-printf( "%d %d\n", div( 13, 5 ) ); §\C{// print quotient/remainder}§
-
-[ double, double ] modf( double x ); §\C{// from include math}§
-printf( "%g %g\n", modf( 13.5 ) ); §\C{// print integral/fractional components}§
+[ int, int ] div( int x, int y );                       §\C{// from include stdlib}§
+printf( "%d %d\n", div( 13, 5 ) );                      §\C{// print quotient/remainder}§
+
+[ double, double ] modf( double x );            §\C{// from include math}§
+printf( "%g %g\n", modf( 13.5 ) );                      §\C{// print integral/fractional components}§
 \end{cfa}
 This approach provides the benefits of compile-time checking for appropriate return statements as in aggregation, but without the required verbosity of declaring a new named type.
@@ -2689 +2426 @@
 \begin{cfa}
 int quot, rem;
-[ quot, rem ] = div( 13, 5 ); §\C{// assign multiple variables}§
-printf( "%d %d\n", quot, rem ); §\C{// print quotient/remainder}\CRT§
+[ quot, rem ] = div( 13, 5 );                           §\C{// assign multiple variables}§
+printf( "%d %d\n", quot, rem );                         §\C{// print quotient/remainder}\CRT§
 \end{cfa}
 Here, the multiple return-values are matched in much the same way as passing multiple return-values to multiple parameters in a call.
@@ -2696 +2433 @@
 
 \subsection{Expressions}
-
-% Change order of expression evaluation.
-% http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
 
 Multiple-return-value functions provide \CFA with a new syntax for expressing a combination of expressions in the return statement and a combination of types in a function signature.
@@ -2719 +2453 @@
 In \CFA, it is possible to overcome this restriction by declaring a \newterm{tuple variable}.
 \begin{cfa}
-[int, int] ®qr® = div( 13, 5 ); §\C{// initialize tuple variable}§
-printf( "%d %d\n", ®qr® ); §\C{// print quotient/remainder}§
+[int, int] ®qr® = div( 13, 5 );                 §\C{// initialize tuple variable}§
+printf( "%d %d\n", ®qr® );                              §\C{// print quotient/remainder}§
 \end{cfa}
 It is now possible to match the multiple return-values to a single variable, in much the same way as \Index{aggregation}.
@@ -2726 +2460 @@
 One way to access the individual components of a tuple variable is with assignment.
 \begin{cfa}
-[ quot, rem ] = qr; §\C{// assign multiple variables}§
+[ quot, rem ] = qr;                                             §\C{// assign multiple variables}§
 \end{cfa}
 
@@ -2749 +2483 @@
 [int, double] * p;
 
-int y = x.0; §\C{// access int component of x}§
-y = f().1; §\C{// access int component of f}§
-p->0 = 5; §\C{// access int component of tuple pointed-to by p}§
-g( x.1, x.0 ); §\C{// rearrange x to pass to g}§
-double z = [ x, f() ].0.1; §\C{// access second component of first component of tuple expression}§
+int y = x.0;                                                    §\C{// access int component of x}§
+y = f().1;                                                              §\C{// access int component of f}§
+p->0 = 5;                                                               §\C{// access int component of tuple pointed-to by p}§
+g( x.1, x.0 );                                                  §\C{// rearrange x to pass to g}§
+double z = [ x, f() ].0.1;                              §\C{// access second component of first component of tuple expression}§
 \end{cfa}
 Tuple-index expressions can occur on any tuple-typed expression, including tuple-returning functions, square-bracketed tuple expressions, and other tuple-index expressions, provided the retrieved component is also a tuple.
@@ -2820 +2554 @@
 double y;
 [int, double] z;
-[y, x] = 3.14; §\C{// mass assignment}§
+[y, x] = 3.14;                                                  §\C{// mass assignment}§
 [x, y] = z;                                                         §\C{// multiple assignment}§
 z = 10;                                                         §\C{// mass assignment}§
-z = [x, y]; §\C{// multiple assignment}§
+z = [x, y];                                                             §\C{// multiple assignment}§
 \end{cfa}
 Let $L_i$ for $i$ in $[0, n)$ represent each component of the flattened left side, $R_i$ represent each component of the flattened right side of a multiple assignment, and $R$ represent the right side of a mass assignment.
@@ -2867 +2601 @@
         double c, d;
         [ void ] f( [ int, int ] );
-        f( [ c, a ] = [ b, d ] = 1.5 ); §\C{// assignments in parameter list}§
+        f( [ c, a ] = [ b, d ] = 1.5 );  // assignments in parameter list
 \end{cfa}
 The tuple expression begins with a mass assignment of ©1.5© into ©[b, d]©, which assigns ©1.5© into ©b©, which is truncated to ©1©, and ©1.5© into ©d©, producing the tuple ©[1, 1.5]© as a result.
@@ -2880 +2614 @@
 \begin{cfa}
 struct S;
-void ?{}(S *); §\C{// (1)}§
-void ?{}(S *, int); §\C{// (2)}§
-void ?{}(S * double); §\C{// (3)}§
-void ?{}(S *, S); §\C{// (4)}§
-
-[S, S] x = [3, 6.28]; §\C{// uses (2), (3), specialized constructors}§
-[S, S] y; §\C{// uses (1), (1), default constructor}§
-[S, S] z = x.0; §\C{// uses (4), (4), copy constructor}§
+void ?{}(S *);         // (1)
+void ?{}(S *, int);    // (2)
+void ?{}(S * double);  // (3)
+void ?{}(S *, S);      // (4)
+
+[S, S] x = [3, 6.28];  // uses (2), (3), specialized constructors
+[S, S] y;              // uses (1), (1), default constructor
+[S, S] z = x.0;        // uses (4), (4), copy constructor
 \end{cfa}
 In this example, ©x© is initialized by the multiple constructor calls ©?{}(&x.0, 3)© and ©?{}(&x.1, 6.28)©, while ©y© is initialized by two default constructor calls ©?{}(&y.0)© and ©?{}(&y.1)©.
@@ -2928 +2662 @@
 A member-access tuple may be used anywhere a tuple can be used, \eg:
 \begin{cfa}
-s.[ y, z, x ] = [ 3, 3.2, 'x' ]; §\C{// equivalent to s.x = 'x', s.y = 3, s.z = 3.2}§
-f( s.[ y, z ] ); §\C{// equivalent to f( s.y, s.z )}§
+s.[ y, z, x ] = [ 3, 3.2, 'x' ];                §\C{// equivalent to s.x = 'x', s.y = 3, s.z = 3.2}§
+f( s.[ y, z ] );                                                §\C{// equivalent to f( s.y, s.z )}§
 \end{cfa}
 Note, the fields appearing in a record-field tuple may be specified in any order;
@@ -2939 +2673 @@
 void f( double, long );
 
-f( x.[ 0, 3 ] ); §\C{// f( x.0, x.3 )}§
-x.[ 0, 1 ] = x.[ 1, 0 ]; §\C{// [ x.0, x.1 ] = [ x.1, x.0 ]}§
+f( x.[ 0, 3 ] );                                                §\C{// f( x.0, x.3 )}§
+x.[ 0, 1 ] = x.[ 1, 0 ];                                §\C{// [ x.0, x.1 ] = [ x.1, x.0 ]}§
 [ long, int, long ] y = x.[ 2, 0, 2 ];
 \end{cfa}
@@ -2957 +2691 @@
 \begin{cfa}
 [ int, float, double ] f();
-[ double, float ] x = f().[ 2, 1 ]; §\C{// f() called once}§
+[ double, float ] x = f().[ 2, 1 ];             §\C{// f() called once}§
 \end{cfa}
 
@@ -2970 +2704 @@
 That is, a cast can be used to select the type of an expression when it is ambiguous, as in the call to an overloaded function.
 \begin{cfa}
-int f(); §\C{// (1)}§
-double f(); §\C{// (2)}§
-
-f(); §\C{// ambiguous - (1),(2) both equally viable}§
-(int)f(); §\C{// choose (2)}§
+int f();     // (1)
+double f();  // (2)
+
+f();       // ambiguous - (1),(2) both equally viable
+(int)f();  // choose (2)
 \end{cfa}
 Since casting is a fundamental operation in \CFA, casts need to be given a meaningful interpretation in the context of tuples.
@@ -2982 +2716 @@
 void g();
 
-(void)f(); §\C{// valid, ignore results}§
-(int)g(); §\C{// invalid, void cannot be converted to int}§
+(void)f();  // valid, ignore results
+(int)g();   // invalid, void cannot be converted to int
 
 struct A { int x; };
-(struct A)f(); §\C{// invalid, int cannot be converted to A}§
+(struct A)f();  // invalid, int cannot be converted to A
 \end{cfa}
 In C, line 4 is a valid cast, which calls ©f© and discards its result.
@@ -3002 +2736 @@
         [int, [int, int], int] g();
 
-        ([int, double])f(); §\C{// (1) valid}§
-        ([int, int, int])g(); §\C{// (2) valid}§
-        ([void, [int, int]])g(); §\C{// (3) valid}§
-        ([int, int, int, int])g(); §\C{// (4) invalid}§
-        ([int, [int, int, int]])g(); §\C{// (5) invalid}§
+        ([int, double])f();           // (1) valid
+        ([int, int, int])g();         // (2) valid
+        ([void, [int, int]])g();      // (3) valid
+        ([int, int, int, int])g();    // (4) invalid
+        ([int, [int, int, int]])g();  // (5) invalid
 \end{cfa}
 
@@ -3066 +2800 @@
 void f([int, int], int, int);
 
-f([0, 0], 0, 0); §\C{// no cost}§
-f(0, 0, 0, 0); §\C{// cost for structuring}§
-f([0, 0,], [0, 0]); §\C{// cost for flattening}§
-f([0, 0, 0], 0); §\C{// cost for flattening and structuring}§
+f([0, 0], 0, 0);    // no cost
+f(0, 0, 0, 0);      // cost for structuring
+f([0, 0,], [0, 0]); // cost for flattening
+f([0, 0, 0], 0);    // cost for flattening and structuring
 \end{cfa}
 
@@ -3132 +2866 @@
 [ unsigned int, char ]
 [ double, double, double ]
-[ * int, int * ] §\C{// mix of CFA and ANSI}§
+[ * int, int * ]                §\C{// mix of CFA and ANSI}§
 [ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ]
 \end{cfa}
@@ -3139 +2873 @@
 Examples of declarations using tuple types are:
 \begin{cfa}
-[ int, int ] x; §\C{// 2 element tuple, each element of type int}§
-* [ char, char ] y; §\C{// pointer to a 2 element tuple}§
+[ int, int ] x;                 §\C{// 2 element tuple, each element of type int}§
+* [ char, char ] y;             §\C{// pointer to a 2 element tuple}§
 [ [ int, int ] ] z ([ int, int ]);
 \end{cfa}
@@ -3157 +2891 @@
 [ int, int ] w1;
 [ int, int, int ] w2;
-[ void ] f (int, int, int); §\C{// three input parameters of type int}§
-[ void ] g ([ int, int, int ]); §\C{3 element tuple as input}§
+[ void ] f (int, int, int); /* three input parameters of type int */
+[ void ] g ([ int, int, int ]); /* 3 element tuple as input */
 f( [ 1, 2, 3 ] );
 f( w1, 3 );
@@ -3238 +2972 @@
 [ int, int, int, int ] w = [ 1, 2, 3, 4 ];
 int x = 5;
-[ x, w ] = [ w, x ]; §\C{// all four tuple coercions}§
+[ x, w ] = [ w, x ];            §\C{// all four tuple coercions}§
 \end{cfa}
 Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values;
@@ -3326 +3060 @@
 both these examples produce indeterminate results:
 \begin{cfa}
-f( x++, x++ ); §\C{// C routine call with side effects in arguments}§
-[ v1, v2 ] = [ x++, x++ ]; §\C{// side effects in righthand side of multiple assignment}§
+f( x++, x++ );                          §\C{// C routine call with side effects in arguments}§
+[ v1, v2 ] = [ x++, x++ ];      §\C{// side effects in righthand side of multiple assignment}§
 \end{cfa}
 
@@ -3349 +3083 @@
 
 
-\section{Stream I/O Library}
-\label{s:StreamIOLibrary}
-\index{input/output stream library}
-\index{stream library}
-
-The goal of \CFA stream input/output (I/O) is to simplify the common cases\index{I/O!common case}, while fully supporting polymorphism and user defined types in a consistent way.
-Stream I/O can be implicitly or explicitly formatted.
-Implicit formatting means \CFA selects the output or input format for values that match with the type of a variable.
-Explicit formatting means additional information is specified to augment how an output or input of value is interpreted.
-\CFA formatting is a cross between C ©printf© and \CC ©cout© manipulators, and Python implicit spacing and newline.
-Specifically:
-\begin{itemize}
-\item
-©printf©/Python format codes are dense, making them difficult to read and remember.
-\CFA/\CC format manipulators are named, making them easier to read and remember.
-\item
-©printf©/Python separates format codes from associated variables, making it difficult to match codes with variables.
-\CFA/\CC co-locate codes with associated variables, where \CFA has the tighter binding.
-\item
-Format manipulators in \CFA have local effect, whereas \CC have global effect, except ©setw©.
-Hence, it is common programming practice to toggle manipulators on and then back to the default to prevent downstream side-effects.
-Without this programming style, errors occur when moving prints, as manipulator effects incorrectly flow into the new location.
-(To guarantee no side-effects, manipulator values must be saved and restored across function calls.)
-\item
-\CFA has more sophisticated implicit spacing between values than Python, plus implicit newline at the end of a print.
-\end{itemize}
-The \CFA header file for the I/O library is \Indexc{fstream.hfa}.
-
-For implicit formatted output, the common case is printing a series of variables separated by whitespace.
+\section{I/O Library}
+\label{s:IOLibrary}
+\index{input/output library}
+
+The goal of \CFA I/O is to simplify the common cases\index{I/O!common case}, while fully supporting polymorphism and user defined types in a consistent way.
+The approach combines ideas from \CC and Python.
+The \CFA header file for the I/O library is \Indexc{fstream}.
+
+The common case is printing out a sequence of variables separated by whitespace.
 \begin{cquote}
-\begin{tabular}{@{}l@{\hspace{2em}}l@{\hspace{2em}}l@{}}
-\multicolumn{1}{c@{\hspace{2em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{\CC}}       & \multicolumn{1}{c}{\textbf{Python}}   \\
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
 \begin{cfa}
 int x = 1, y = 2, z = 3;
-sout | x ®|® y ®|® z;
+sout | x ®|® y ®|® z | endl;
 \end{cfa}
 &
@@ -3389 +3103 @@
 
 cout << x ®<< " "® << y ®<< " "® << z << endl;
-\end{cfa}
-&
-\begin{cfa}
-x = 1;  y = 2;  z = 3
-print( x, y, z )
 \end{cfa}
 \\
@@ -3401 +3110 @@
 &
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-1® ®2® ®3
-\end{cfa}
-&
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-1® ®2® ®3
+1 2 3
 \end{cfa}
 \end{tabular}
 \end{cquote}
-The \CFA form has half the characters of the \CC form, and is similar to \Index*{Python} I/O with respect to implicit separators and newline.
-Similar simplification occurs for \Index{tuple} I/O, which flattens the tuple and prints each value separated by ``\lstinline[showspaces=true]@, @''.
+The \CFA form has half the characters of the \CC form, and is similar to \Index*{Python} I/O with respect to implicit separators.
+Similar simplification occurs for \Index{tuple} I/O, which prints all tuple values separated by ``\lstinline[showspaces=true]@, @''.
 \begin{cfa}
 [int, [ int, int ] ] t1 = [ 1, [ 2, 3 ] ], t2 = [ 4, [ 5, 6 ] ];
-sout | t1 | t2; §\C{// print tuples}§
+sout | t1 | t2 | endl;                                  §\C{// print tuples}§
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt]
 1®, ®2®, ®3 4®, ®5®, ®6
 \end{cfa}
-Finally, \CFA uses the logical-or operator for I/O as it is the lowest-priority \emph{overloadable} operator, other than assignment.
+Finally, \CFA uses the logical-or operator for I/O as it is the lowest-priority overloadable operator, other than assignment.
 Therefore, fewer output expressions require parenthesis.
 \begin{cquote}
@@ -3425 +3130 @@
 &
 \begin{cfa}
-sout | x * 3 | y + 1 | z << 2 | x == y | ®(®x | y®)® | ®(®x || y®)® | ®(®x > z ? 1 : 2®)®;
+sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
 \end{cfa}
 \\
@@ -3431 +3136 @@
 &
 \begin{cfa}
-cout << x * 3 << y + 1 << ®(®z << 2®)® << ®(®x == y®)® << ®(®x | y®)® << ®(®x || y®)® << ®(®x > z ? 1 : 2®)® << endl;
+cout << x * 3 << y + 1 << ®(®z << 2®)® << ®(®x == y®)® << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
 \end{cfa}
 \\
@@ -3440 +3145 @@
 \end{tabular}
 \end{cquote}
-Input and output use a uniform operator, ©|©, rather than separate operators, as in ©>>© and ©<<© for \CC.
-There is a weak similarity between the \CFA logical-or operator and the \Index{Shell pipe-operator} for moving data, where data flows in the correct direction for input but the opposite direction for output.
-
-For implicit formatted input, the common case is reading a sequence of values separated by whitespace, where the type of an input constant must match with the type of the input variable.
-\begin{cquote}
-\begin{lrbox}{\LstBox}
-\begin{cfa}[aboveskip=0pt,belowskip=0pt]
-int x;   double y   char z;
-\end{cfa}
-\end{lrbox}
-\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{3em}}l@{}}
-\multicolumn{1}{@{}l@{}}{\usebox\LstBox} \\
-\multicolumn{1}{c@{\hspace{2em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{\CC}}       & \multicolumn{1}{c}{\textbf{Python}}   \\
-\begin{cfa}[aboveskip=0pt,belowskip=0pt]
-sin | x | y | z;
-\end{cfa}
-&
-\begin{cfa}[aboveskip=0pt,belowskip=0pt]
-cin >> x >> y >> z;
-\end{cfa}
-&
-\begin{cfa}[aboveskip=0pt,belowskip=0pt]
-x = int(input());  y = float(input());  z = input();
-\end{cfa}
-\\
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®1® ®2.5® ®A®
-
-
-\end{cfa}
-&
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®1® ®2.5® ®A®
-
-
-\end{cfa}
-&
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®1®
-®2.5®
-®A®
-\end{cfa}
-\end{tabular}
-\end{cquote}
-
+There is a weak similarity between the \CFA logical-or operator and the Shell pipe-operator for moving data, where data flows in the correct direction for input but the opposite direction for output.
 
 
 \subsection{Implicit Separator}
 
-The \Index{implicit separator}\index{I/O!separator} character (space/blank) is a separator not a terminator for output.
+The \Index{implicit separator}\index{I/O!separator} character (space/blank) is a separator not a terminator.
 The rules for implicitly adding the separator are:
 \begin{enumerate}
@@ -3495 +3156 @@
 A separator does not appear at the start or end of a line.
 \begin{cfa}[belowskip=0pt]
-sout | 1 | 2 | 3;
+sout | 1 | 2 | 3 | endl;
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3504 +3165 @@
 A separator does not appear before or after a character literal or variable.
 \begin{cfa}
-sout | '1' | '2' | '3';
+sout | '1' | '2' | '3' | endl;
 123
 \end{cfa}
 
 \item
-A separator does not appear before or after a null (empty) C string, which is a local mechanism to disable insertion of the separator character.
-\begin{cfa}
-sout | 1 | "" | 2 | "" | 3;
+A separator does not appear before or after a null (empty) C string.
+\begin{cfa}
+sout | 1 | "" | 2 | "" | 3 | endl;
 123
 \end{cfa}
+which is a local mechanism to disable insertion of the separator character.
+
+\item
+A separator does not appear before a C string starting with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off,basicstyle=\tt]@([{=$£¥¡¿«@
+%$
+\begin{cfa}[mathescape=off]
+sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
+                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
+\end{cfa}
+%$
+\begin{cfa}[mathescape=off,basicstyle=\tt,showspaces=true,aboveskip=0pt,belowskip=0pt]
+x ®(®1 x ®[®2 x ®{®3 x ®=®4 x ®$®5 x ®£®6 x ®¥®7 x ®¡®8 x ®¿®9 x ®«®10
+\end{cfa}
+%$
+where \lstinline[basicstyle=\tt]@¡¿@ are inverted opening exclamation and question marks, and \lstinline[basicstyle=\tt]@«@ is an opening citation mark.
 
 \item
 {\lstset{language=CFA,deletedelim=**[is][]{¢}{¢}}
-A separator does not appear before a C string starting with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[basicstyle=\tt]@,.;!?)]}%¢»@, where \lstinline[basicstyle=\tt]@»@ is a closing citation mark.
+A seperator does not appear after a C string ending with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[basicstyle=\tt]@,.;!?)]}%¢»@
 \begin{cfa}[belowskip=0pt]
 sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
-                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x";
+                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
 \end{cfa}
 \begin{cfa}[basicstyle=\tt,showspaces=true,aboveskip=0pt,belowskip=0pt]
 1®,® x 2®.® x 3®;® x 4®!® x 5®?® x 6®%® x 7§\color{red}\textcent§ x 8®»® x 9®)® x 10®]® x 11®}® x
 \end{cfa}}%
-
-\item
-A separator does not appear after a C string ending with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off,basicstyle=\tt]@([{=$£¥¡¿«@, where \lstinline[basicstyle=\tt]@¡¿@ are inverted opening exclamation and question marks, and \lstinline[basicstyle=\tt]@«@ is an opening citation mark.
-%$
-\begin{cfa}[mathescape=off]
-sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
-                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10;
-\end{cfa}
-%$
-\begin{cfa}[mathescape=off,basicstyle=\tt,showspaces=true,aboveskip=0pt,belowskip=0pt]
-x ®(®1 x ®[®2 x ®{®3 x ®=®4 x ®$®5 x ®£®6 x ®¥®7 x ®¡®8 x ®¿®9 x ®«®10
-\end{cfa}
-%$
-
-\item
-A seperator does not appear before/after a C string starting/ending with the \Index*{ASCII} quote or whitespace characters: \lstinline[basicstyle=\tt,showspaces=true]@`'": \t\v\f\r\n@
+where \lstinline[basicstyle=\tt]@»@ is a closing citation mark.
+
+\item
+A seperator does not appear before or after a C string begining/ending with the \Index*{ASCII} quote or whitespace characters: \lstinline[basicstyle=\tt,showspaces=true]@`'": \t\v\f\r\n@
 \begin{cfa}[belowskip=0pt]
-sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx";
+sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx" | endl;
 \end{cfa}
 \begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
@@ -3551 +3215 @@
 If a space is desired before or after one of the special string start/end characters, simply insert a space.
 \begin{cfa}[belowskip=0pt]
-sout | "x (§\color{red}\texttt{\textvisiblespace}§" | 1 | "§\color{red}\texttt{\textvisiblespace}§) x" | 2 | "§\color{red}\texttt{\textvisiblespace}§, x" | 3 | "§\color{red}\texttt{\textvisiblespace}§:x:§\color{red}\texttt{\textvisiblespace}§" | 4;
+sout | "x (§\color{red}\texttt{\textvisiblespace}§" | 1 | "§\color{red}\texttt{\textvisiblespace}§) x" | 2 | "§\color{red}\texttt{\textvisiblespace}§, x" | 3 | "§\color{red}\texttt{\textvisiblespace}§:x:§\color{red}\texttt{\textvisiblespace}§" | 4 | endl;
 \end{cfa}
 \begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
@@ -3559 +3223 @@
 
 
-\subsection{Separation Manipulators}
-
-The following \Index{manipulator}s control \Index{implicit output separation}.
-The effect of these manipulators is global for an output stream (except ©sepOn© and ©sepOff©).
+\subsection{Manipulator}
+
+The following \CC-style \Index{manipulator}s and routines control implicit seperation.
 \begin{enumerate}
 \item
-\Indexc{sepSet}\index{manipulator!sepSet@©sepSet©} and \Indexc{sep}\index{manipulator!sep@©sep©}/\Indexc{sepGet}\index{manipulator!sepGet@©sepGet©} set and get the separator string.
+Routines \Indexc{sepSet}\index{manipulator!sepSet@©sepSet©} and \Indexc{sep}\index{manipulator!sep@©sep©}/\Indexc{sepGet}\index{manipulator!sepGet@©sepGet©} set and get the separator string.
 The separator string can be at most 16 characters including the ©'\0'© string terminator (15 printable characters).
 \begin{cfa}[mathescape=off,belowskip=0pt]
-sepSet( sout, ", $" ); §\C{// set separator from " " to ", \$"}§
-sout | 1 | 2 | 3 | " \"" | ®sep® | "\"";
+sepSet( sout, ", $" );                                          §\C{// set separator from " " to ", \$"}§
+sout | 1 | 2 | 3 | " \"" | ®sep® | "\"" | endl;
 \end{cfa}
 %$
@@ -3577 +3240 @@
 %$
 \begin{cfa}[belowskip=0pt]
-sepSet( sout, " " ); §\C{// reset separator to " "}§
-sout | 1 | 2 | 3 | " \"" | ®sepGet( sout )® | "\"";
+sepSet( sout, " " );                                            §\C{// reset separator to " "}§
+sout | 1 | 2 | 3 | " \"" | ®sepGet( sout )® | "\"" | endl;
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt]
@@ -3585 +3248 @@
 ©sepGet© can be used to store a separator and then restore it:
 \begin{cfa}[belowskip=0pt]
-char store[®sepSize®]; §\C{// sepSize is the maximum separator size}§
-strcpy( store, sepGet( sout ) ); §\C{// copy current separator}§
-sepSet( sout, "_" ); §\C{// change separator to underscore}§
-sout | 1 | 2 | 3;
+char store[®sepSize®];                                          §\C{// sepSize is the maximum separator size}§
+strcpy( store, sepGet( sout ) );                          §\C{// copy current separator}§
+sepSet( sout, "_" );                                            §\C{// change separator to underscore}§
+sout | 1 | 2 | 3 | endl;
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3594 +3257 @@
 \end{cfa}
 \begin{cfa}[belowskip=0pt]
-sepSet( sout, store ); §\C{// change separator back to original}§
-sout | 1 | 2 | 3;
+sepSet( sout, store );                                          §\C{// change separator back to original}§
+sout | 1 | 2 | 3 | endl;
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt]
@@ -3602 +3265 @@
 
 \item
-\Indexc{sepSetTuple}\index{manipulator!sepSetTuple@©sepSetTuple©} and \Indexc{sepTuple}\index{manipulator!sepTuple@©sepTuple©}/\Indexc{sepGetTuple}\index{manipulator!sepGetTuple@©sepGetTuple©} get and set the tuple separator-string.
+Routine \Indexc{sepSetTuple}\index{manipulator!sepSetTuple@©sepSetTuple©} and \Indexc{sepTuple}\index{manipulator!sepTuple@©sepTuple©}/\Indexc{sepGetTuple}\index{manipulator!sepGetTuple@©sepGetTuple©} get and set the tuple separator-string.
 The tuple separator-string can be at most 16 characters including the ©'\0'© string terminator (15 printable characters).
 \begin{cfa}[belowskip=0pt]
-sepSetTuple( sout, " " ); §\C{// set tuple separator from ", " to " "}§
-sout | t1 | t2 | " \"" | ®sepTuple® | "\"";
+sepSetTuple( sout, " " );                                       §\C{// set tuple separator from ", " to " "}§
+sout | t1 | t2 | " \"" | ®sepTuple® | "\"" | endl;
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt]
@@ -3612 +3275 @@
 \end{cfa}
 \begin{cfa}[belowskip=0pt]
-sepSetTuple( sout, ", " ); §\C{// reset tuple separator to ", "}§
-sout | t1 | t2 | " \"" | ®sepGetTuple( sout )® | "\"";
+sepSetTuple( sout, ", " );                                      §\C{// reset tuple separator to ", "}§
+sout | t1 | t2 | " \"" | ®sepGetTuple( sout )® | "\"" | endl;
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt]
@@ -3621 +3284 @@
 
 \item
-\Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} toggle printing the separator.
+Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} \emph{globally} toggle printing the separator, \ie the seperator is adjusted with respect to all subsequent printed items.
 \begin{cfa}[belowskip=0pt]
-sout | sepDisable | 1 | 2 | 3; §\C{// turn off implicit separator}§
+sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// globally turn off implicit separator}§
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3629 +3292 @@
 \end{cfa}
 \begin{cfa}[belowskip=0pt]
-sout | sepEnable | 1 | 2 | 3; §\C{// turn on implicit separator}§
+sout | sepEnable | 1 | 2 | 3 | endl;            §\C{// globally turn on implicit separator}§
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3636 +3299 @@
 
 \item
-\Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} toggle printing the separator with respect to the next printed item, and then return to the global seperator setting.
+Manipulators \Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} \emph{locally} toggle printing the separator, \ie the seperator is adjusted only with respect to the next printed item.
 \begin{cfa}[belowskip=0pt]
-sout | 1 | sepOff | 2 | 3; §\C{// turn off implicit separator for the next item}§
+sout | 1 | sepOff | 2 | 3 | endl;                       §\C{// locally turn off implicit separator}§
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3644 +3307 @@
 \end{cfa}
 \begin{cfa}[belowskip=0pt]
-sout | sepDisable | 1 | sepOn | 2 | 3; §\C{// turn on implicit separator for the next item}§
+sout | sepDisable | 1 | sepOn | 2 | 3 | endl; §\C{// locally turn on implicit separator}§
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3651 +3314 @@
 The tuple separator also responses to being turned on and off.
 \begin{cfa}[belowskip=0pt]
-sout | t1 | sepOff | t2; §\C{// turn off implicit separator for the next item}§
+sout | t1 | sepOff | t2 | endl;                         §\C{// locally turn on/off implicit separator}§
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3659 +3322 @@
 use ©sep© to accomplish this functionality.
 \begin{cfa}[belowskip=0pt]
-sout | sepOn | 1 | 2 | 3 | sepOn; §\C{// sepOn does nothing at start/end of line}§
+sout | sepOn | 1 | 2 | 3 | sepOn | endl ;       §\C{// sepOn does nothing at start/end of line}§
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3665 +3328 @@
 \end{cfa}
 \begin{cfa}[belowskip=0pt]
-sout | sep | 1 | 2 | 3 | sep ; §\C{// use sep to print separator at start/end of line}§
+sout | sep | 1 | 2 | 3 | sep | endl ;           §\C{// use sep to print separator at start/end of line}§
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
 ® ®1 2 3® ®
-\end{cfa}
-\end{enumerate}
-
-
-\subsection{Newline Manipulators}
-
-The following \Index{manipulators} control \Index{newline separation} for input and output.
-
-For input:
-\begin{enumerate}[parsep=0pt]
-\item
-\Indexc{nl}\index{manipulator!nl@©nl©} scans characters until the next newline character, i.e., ignore the remaining characters in the line.
-\item
-\Indexc{nlOn}\index{manipulator!nlOn@©nlOn©} reads the newline character, when reading single characters.
-\item
-\Indexc{nlOff}\index{manipulator!nlOff@©nlOff©} does \emph{not} read the newline character, when reading single characters.
-\end{enumerate}
-For example, in:
-\begin{cfa}
-sin | i | ®nl® | j;
-1 ®2®
-3
-\end{cfa}
-variable ©i© is assigned 1, the 2 is skipped, and variable ©j© is assigned 3.
-
-For output:
-\begin{enumerate}[parsep=0pt]
-\item
-\Indexc{nl}\index{manipulator!nl@©nl©} inserts a newline.
-\begin{cfa}
-sout | nl; §\C{// only print newline}§
-sout | 2; §\C{// implicit newline}§
-sout | 3 | nl | 4 | nl; §\C{// terminating nl merged with implicit newline}§
-sout | 5 | nl | nl; §\C{// again terminating nl merged with implicit newline}§
-sout | 6; §\C{// implicit newline}§
-
-2
-3
-4
-5
-
-6
-\end{cfa}
-Note, a terminating ©nl© is merged (overrides) with the implicit newline at the end of the ©sout© expression, otherwise it is impossible to to print a single newline
-\item
-\Indexc{nlOn}\index{manipulator!nlOn@©nlOn©} implicitly prints a newline at the end of each output expression.
-\item
-\Indexc{nlOff}\index{manipulator!nlOff@©nlOff©} does \emph{not} implicitly print a newline at the end of each output expression.
-\end{enumerate}
-
-
-\subsection{Output Value Manipulators}
-
-The following \Index{manipulator}s control formatting of output values (printing), and only affect the format of the argument.
-\begin{enumerate}
-\item
-\Indexc{bin}( integer )\index{manipulator!bin@©bin©} print value in base 2 preceded by ©0b©/©0B©.
-\begin{cfa}[belowskip=0pt]
-sout | bin( 0 ) | bin( 27HH ) | bin( 27H ) | bin( 27 ) | bin( 27L );
-0b0 0b11011 0b11011 0b11011 0b11011
-sout | bin( -27HH ) | bin( -27H ) | bin( -27 ) | bin( -27L );
-0b11100101 0b1111111111100101 0b11111111111111111111111111100101 0b®(58 1s)®100101
-\end{cfa}
-
-\item
-\Indexc{oct}( integer )\index{manipulator!oct@©oct©} print value in base 8 preceded by ©0©.
-\begin{cfa}[belowskip=0pt]
-sout | oct( 0 ) | oct( 27HH ) | oct( 27H ) | oct( 27 ) | oct( 27L );
-0 033 033 033 033
-sout | oct( -27HH ) | oct( -27H ) | oct( -27 ) | oct( -27L );
-0345 0177745 037777777745 01777777777777777777745
-\end{cfa}
-Note, octal 0 is \emph{not} preceded by ©0© to prevent confusion.
-
-\item
-\Indexc{hex}( integer / floating-point )\index{manipulator!hex@©hex©} print value in base 16 preceded by ©0x©/©0X©.
-\begin{cfa}[belowskip=0pt]
-sout | hex( 0 ) | hex( 27HH ) | hex( 27H ) | hex( 27 ) | hex( 27L );
-0 0x1b 0x1b 0x1b 0x1b
-sout | hex( -27HH ) | hex( -27H ) | hex( -27 ) | hex( -27L );
-0xe5 0xffe5 0xffffffe5 0xffffffffffffffe5
-
-sout | hex( 0.0 ) | hex( 27.5F ) | hex( 27.5 ) | hex( 27.5L );
-0x0.p+0 0x1.b8p+4 0x1.b8p+4 0xd.cp+1
-sout | hex( -27.5F ) | hex( -27.5 ) | hex( -27.5L );
--0x1.b8p+4 -0x1.b8p+4 -0xd.cp+1
-\end{cfa}
-
-\item
-\Indexc{sci}( floating-point )\index{manipulator!sci@©sci©} print value in scientific notation with exponent.
-Default is 6 digits of precision.
-\begin{cfa}[belowskip=0pt]
-sout | sci( 0.0 ) | sci( 27.5 ) | sci( -27.5 );
-0.000000e+00 2.750000e+01 -2.750000e+01
-\end{cfa}
-
-\item
-\Indexc{upcase}( bin / hex / floating-point )\index{manipulator!upcase@©upcase©} print letters in a value in upper case. Lower case is the default.
-\begin{cfa}[belowskip=0pt]
-sout | upcase( bin( 27 ) ) | upcase( hex( 27 ) ) | upcase( 27.5e-10 ) | upcase( hex( 27.5 ) );
-0®B®11011 0®X®1®B® 2.75®E®-09 0®X®1.®B®8®P®+4
-\end{cfa}
-
-\item
-\Indexc{nobase}( integer )\index{manipulator!nobase@©nobase©} do not precede ©bin©, ©oct©, ©hex© with ©0b©/©0B©, ©0©, or ©0x©/©0X©.
-Printing the base is the default.
-\begin{cfa}[belowskip=0pt]
-sout | nobase( bin( 27 ) ) | nobase( oct( 27 ) ) | nobase( hex( 27 ) );
-11011 33 1b
-\end{cfa}
-
-\item
-\Indexc{nodp}( floating-point )\index{manipulator!nodp@©nodp©} do not print a decimal point if there are no fractional digits.
-Printing a decimal point is the default, if there are no fractional digits.
-\begin{cfa}[belowskip=0pt]
-sout | 0. | nodp( 0. ) | 27.0 | nodp( 27.0 ) | nodp( 27.5 );
-0.0 ®0® 27.0 ®27® 27.5
-\end{cfa}
-
-\item
-\Indexc{sign}( integer / floating-point )\index{manipulator!sign@©sign©} prefix with plus or minus sign (©+© or ©-©). Only printing the minus sign is the default.
-\begin{cfa}[belowskip=0pt]
-sout | sign( 27 ) | sign( -27 ) | sign( 27. ) | sign( -27. ) | sign( 27.5 ) | sign( -27.5 );
-®+®27 -27 ®+®27.0 -27.0 ®+®27.5 -27.5
-\end{cfa}
-
-\item
-\Indexc{wd}©( unsigned char minimum, T val )©\index{manipulator!wd@©wd©}, ©wd( unsigned char minimum, unsigned char precision, T val )©
-For all types, ©minimum© is the minimum number of printed characters.
-If the value is shorter than the minimum, it is padded on the right with spaces.
-\begin{cfa}[belowskip=0pt]
-sout | wd( 4, 34) | wd( 3, 34 ) | wd( 2, 34 );
-sout | wd( 10, 4.) | wd( 9, 4. ) | wd( 8, 4. );
-sout | wd( 4, "ab" ) | wd( 3, "ab" ) | wd( 2, "ab" );
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®  ®34 ® ®34 34
-®  ®4.000000 ® ®4.000000 4.000000
-®  ®ab ® ®ab ab
-\end{cfa}
-If the value is larger, it is printed without truncation, ignoring the ©minimum©.
-\begin{cfa}[belowskip=0pt]
-sout | wd( 4, 34567 ) | wd( 3, 34567 ) | wd( 2, 34567 );
-sout | wd( 4, 3456. ) | wd( 3, 3456. ) | wd( 2, 3456. );
-sout | wd( 4, "abcde" ) | wd( 3, "abcde" ) | wd( 2,"abcde" );
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-3456®7® 345®67® 34®567®
-3456®.® 345®6.® 34®56.®
-abcd®e® abc®de® ab®cde®
-\end{cfa}
-
-For integer types, ©precision© is the minimum number of printed digits.
-If the value is shorter, it is padded on the left with leading zeros.
-\begin{cfa}[belowskip=0pt]
-sout | wd( 4,3, 34 ) | wd( 8,4, 34 ) | wd( 10,10, 34 );
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
- ®0®34     ®00®34 ®00000000®34
-\end{cfa}
-If the value is larger, it is printed without truncation, ignoring the ©precision©.
-\begin{cfa}[belowskip=0pt]
-sout | wd( 4,1, 3456 ) | wd( 8,2, 3456 ) | wd( 10,3, 3456 );
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-3456     3456       3456
-\end{cfa}
-If ©precision© is 0, nothing is printed for zero.
-If ©precision© is greater than the minimum, it becomes the minimum.
-\begin{cfa}[belowskip=0pt]
-sout | wd( 4,0, 0 ) | wd( 3,10, 34 );
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®    ® ®00000000®34
-\end{cfa}
-For floating-point types, ©precision© is the minimum number of digits after the decimal point.
-\begin{cfa}[belowskip=0pt]
-sout | wd( 6,3, 27.5 ) | wd( 8,1, 27.5 ) | wd( 8,0, 27.5 ) | wd( 3,8, 27.5 );
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-27.®500®     27.®5®      28. 27.®50000000®
-\end{cfa}
-For the C-string type, ©precision© is the maximum number of printed characters, so the string is truncared if it exceeds the maximum.
-\begin{cfa}[belowskip=0pt]
-sout | wd( 6,8, "abcd" ) | wd( 6,8, "abcdefghijk" ) | wd( 6,3, "abcd" );
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-  abcd abcdefgh    abc
-\end{cfa}
-
-\item
-\Indexc{ws( unsigned char minimum, unsigned char significant, floating-point )}\index{manipulator!ws@©ws©}
-For floating-point type, ©minimum© is the same as for manipulator ©wd©, but ©significant© is the maximum number of significant digits to be printed for both the integer and fractions (versus only the fraction for ©wd©).
-If a value's significant digits is greater than ©significant©, the last significant digit is rounded up.
-\begin{cfa}[belowskip=0pt]
-sout | ws(6,6, 234.567) | ws(6,5, 234.567) | ws(6,4, 234.567) | ws(6,3, 234.567);
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-234.567 234.5®7®  234.®6®    23®5®
-\end{cfa}
-If a value's magnitude is greater than ©significant©, the value is printed in scientific notation with the specified number of significant digits.
-\begin{cfa}[belowskip=0pt]
-sout | ws(6,6, 234567.) | ws(6,5, 234567.) | ws(6,4, 234567.) | ws(6,3, 234567.);
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-234567. 2.3457®e+05® 2.346®e+05® 2.35®e+05®
-\end{cfa}
-If ©significant© is greater than ©minimum©, it defines the number of printed characters.
-\begin{cfa}[belowskip=0pt]
-sout | ws(3,6, 234567.) | ws(4,6, 234567.) | ws(5,6, 234567.) | ws(6,6, 234567.);
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-234567. 234567. 234567. 234567.
-\end{cfa}
-
-\item
-\Indexc{left}( field-width )\index{manipulator!left@©left©} left justify within the given field.
-\begin{cfa}[belowskip=0pt]
-sout | left(wd(4, 27)) | left(wd(10, 27.)) | left(wd(10, 27.5)) | left(wd(4,3, 27)) | left(wd(10,3, 27.5));
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-27®  ® 27.000000  27.500000  027  27.500®    ®
-\end{cfa}
-
-\item
-\Indexc{pad0}( field-width )\index{manipulator!pad0@©pad0©} left pad with zeroes (0).
-\begin{cfa}[belowskip=0pt]
-sout | pad0( wd( 4, 27 ) ) | pad0( wd( 4,3, 27 ) ) | pad0( wd( 8,3, 27.5 ) );
-®00®27  ®0®27 ®00®27.500
 \end{cfa}
 \end{enumerate}
@@ -3907 +3341 @@
 int main( void ) {
         int x = 1, y = 2, z = 3;
-        sout | x | y | z;
+        sout | x | y | z | endl;
         [int, [ int, int ] ] t1 = [ 1, [ 2, 3 ] ], t2 = [ 4, [ 5, 6 ] ];
-        sout | t1 | t2;                                         // print tuples
-        sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2);
-        sout | 1 | 2 | 3;
-        sout | '1' | '2' | '3';
-        sout | 1 | "" | 2 | "" | 3;
+        sout | t1 | t2 | endl;                                          // print tuples
+        sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
+        sout | 1 | 2 | 3 | endl;
+        sout | '1' | '2' | '3' | endl;
+        sout | 1 | "" | 2 | "" | 3 | endl;
         sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
-                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10;
+                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
         sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
-                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x";
-        sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx";
-        sout | "x ( " | 1 | " ) x" | 2 | " , x" | 3 | " :x: " | 4;
+                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
+        sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx" | endl;
+        sout | "x ( " | 1 | " ) x" | 2 | " , x" | 3 | " :x: " | 4 | endl;
 
         sepSet( sout, ", $" );                                          // set separator from " " to ", $"
-        sout | 1 | 2 | 3 | " \"" | sep | "\"";
+        sout | 1 | 2 | 3 | " \"" | sep | "\"" | endl;
         sepSet( sout, " " );                                            // reset separator to " "
-        sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"";
+        sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
 
         char store[sepSize];
         strcpy( store, sepGet( sout ) );
         sepSet( sout, "_" );
-        sout | 1 | 2 | 3;
+        sout | 1 | 2 | 3 | endl;
         sepSet( sout, store );
-        sout | 1 | 2 | 3;
+        sout | 1 | 2 | 3 | endl;
 
         sepSetTuple( sout, " " );                                       // set tuple separator from ", " to " "
-        sout | t1 | t2 | " \"" | sepTuple | "\"";
+        sout | t1 | t2 | " \"" | sepTuple | "\"" | endl;
         sepSetTuple( sout, ", " );                                      // reset tuple separator to ", "
-        sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"";
-
-        sout | sepDisable | 1 | 2 | 3;          // globally turn off implicit separator
-        sout | sepEnable | 1 | 2 | 3;           // globally turn on implicit separator
-
-        sout | 1 | sepOff | 2 | 3;                      // locally turn on implicit separator
-        sout | sepDisable | 1 | sepOn | 2 | 3; // globally turn off implicit separator
+        sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"" | endl;
+
+        sout | sepDisable | 1 | 2 | 3 | endl;           // globally turn off implicit separator
+        sout | sepEnable | 1 | 2 | 3 | endl;            // globally turn on implicit separator
+        
+        sout | 1 | sepOff | 2 | 3 | endl;                       // locally turn on implicit separator
+        sout | sepDisable | 1 | sepOn | 2 | 3 | endl; // globally turn off implicit separator
         sout | sepEnable;
-        sout | t1 | sepOff | t2;                                // locally turn on/off implicit separator
-
-        sout | sepOn | 1 | 2 | 3 | sepOn ;      // sepOn does nothing at start/end of line
-        sout | sep | 1 | 2 | 3 | sep ;          // use sep to print separator at start/end of line
+        sout | t1 | sepOff | t2 | endl;                         // locally turn on/off implicit separator
+
+        sout | sepOn | 1 | 2 | 3 | sepOn | endl ;       // sepOn does nothing at start/end of line
+        sout | sep | 1 | 2 | 3 | sep | endl ;           // use sep to print separator at start/end of line
 }
 
@@ -3956 +3390 @@
 \end{comment}
 %$
-
-
-\subsection{Input Value Manipulators}
-
-The format of numeric input values in the same as C constants without a trailing type suffix, as the input value-type is denoted by the input variable.
-For ©_Bool© type, the constants are ©true© and ©false©.
-For integral types, any number of digits, optionally preceded by a sign (©+© or ©-©), where a
-\begin{itemize}
-\item
-©1©-©9© prefix introduces a decimal value (©0©-©9©),
-\item
-©0© prefix introduces an octal value (©0©-©7©), and
-\item
-©0x© or ©0X© prefix introduces a hexadecimal value (©0©-©f©) with lower or upper case letters.
-\end{itemize}
-For floating-point types, any number of decimal digits, optionally preceded by a sign (©+© or ©-©), optionally containing a decimal point, and optionally followed by an exponent, ©e© or ©E©, with signed (optional) decimal digits.
-Floating-point values can also be written in hexadecimal format preceded by ©0x© or ©0X© with hexadecimal digits and exponent denoted by ©p© or ©P©.
-
-For the C-string type, the input values are \emph{not} the same as C-string constants, \ie double quotes bracketing arbitrary text with escape sequences.
-Instead, the next sequence of non-whitespace characters are read, and the input sequence is terminated with delimiter ©'\0'©.
-The string variable \emph{must} be large enough to contain the input sequence.
-
-The following \Index{manipulator}s control formatting of input values (reading), and only affect the format of the argument.
-
-\begin{enumerate}
-\item
-\Indexc{skip( const char * pattern )}\index{manipulator!skip@©skip©} / ©skip( unsigned int length )© / ©const char * pattern©
-The argument defines a ©pattern© or ©length©.
-The ©pattern© is composed of white-space and non-white-space characters, where \emph{any} white-space character matches 0 or more input white-space characters (hence, consecutive white-space characters in the pattern are combined), and each non-white-space character matches exactly with an input character.
-The ©length© is composed of the next $N$ characters, including the newline character.
-If the match successes, the input characters are discarded, and input continues with the next character.
-If the match fails, the input characters are left unread.
-\begin{cfa}[belowskip=0pt]
-char sk[$\,$] = "abc";
-sin | "abc " | skip( sk ) | skip( 5 ); // match input sequence
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®abc   ®
-®abc  ®
-®xx®
-\end{cfa}
-
-\item
-\Indexc{wdi}©( unsigned int maximum, T & val )©\index{manipulator!wdi@©wdi©}
-For all types except ©char©, ©maximum© is the maximum number of characters read for the current operation.
-\begin{cfa}[belowskip=0pt]
-char s[10];   int i;   double d;   
-sin | wdi( 4, s ) | wdi( 3, i ) | wdi( 8, d );  // c == "abcd", i == 123, d == 3.456E+2
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®abcd1233.456E+2®
-\end{cfa}
-Note, input ©wdi© cannot be overloaded with output ©wd© because both have the same parameters but return different types.
-Currently, \CFA cannot distinguish between these two manipulators in the middle of an ©sout©/©sin© expression based on return type.
-
-\item
-\Indexc{ignore( T & val )}\index{manipulator!ignore@©ignore©}
-For all types, the data is read from the stream depending on the argument type but ignored, \ie it is not stored in the argument.
-\begin{cfa}[belowskip=0pt]
-double d;
-sin | ignore( d );  // d is unchanged
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®  -75.35e-4® 25
-\end{cfa}
-
-\item
-\Indexc{incl( const char * scanset, char * s )}\index{manipulator!incl@©incl©}
-For the C-string type, the argument defines a ©scanset© that matches any number of characters \emph{in} the set.
-Matching characters are read into the C string and null terminated.
-\begin{cfa}[belowskip=0pt]
-char s[10];
-sin | incl( "abc", s );
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®bca®xyz
-\end{cfa}
-
-\item
-\Indexc{excl( const char * scanset, char * s )}\index{manipulator!excl@©excl©}
-For the C-string type, the argument defines a ©scanset© that matches any number of characters \emph{not in} the set.
-Non-matching characters are read into the C string and null terminated.
-\begin{cfa}[belowskip=0pt]
-char s[10];
-sin | excl( "abc", s );
-\end{cfa}
-\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®xyz®bca
-\end{cfa}
-\end{enumerate}
 
 
@@ -4415 +3759 @@
 \begin{itemize}
 \item
-not determining or writing long generic types,
-\item
-ensuring secondary variables, related to a primary variable, always have the same type.
+preventing having to determine or write long generic types,
+\item
+ensure secondary variables, related to a primary variable, always have the same type.
 \end{itemize}
 
@@ -4439 +3783 @@
 There is also the conundrum in type inferencing of when to \emph{\Index{brand}} a type.
 That is, when is the type of the variable more important than the type of its initialization expression.
-For example, if a change is made in an initialization expression, it can cause cascading type changes and/or errors.
+For example, if a change is made in an initialization expression, it can cause significant cascading type changes and/or errors.
 At some point, a variable type needs to remain constant and the expression to be in error when it changes.
 
@@ -4672 +4016 @@
 
 coroutine Fibonacci {
-        int fn; §\C{// used for communication}§
+        int fn;                                                         §\C{// used for communication}§
 };
 void ?{}( Fibonacci * this ) {
@@ -4678 +4022 @@
 }
 void main( Fibonacci * this ) {
-        int fn1, fn2; §\C{// retained between resumes}§
-        this->fn = 0; §\C{// case 0}§
+        int fn1, fn2;                                           §\C{// retained between resumes}§
+        this->fn = 0;                                           §\C{// case 0}§
         fn1 = this->fn;
-        suspend(); §\C{// return to last resume}§
-
-        this->fn = 1; §\C{// case 1}§
+        suspend();                                                      §\C{// return to last resume}§
+
+        this->fn = 1;                                           §\C{// case 1}§
         fn2 = fn1;
         fn1 = this->fn;
-        suspend(); §\C{// return to last resume}§
-
-        for ( ;; ) { §\C{// general case}§
+        suspend();                                                      §\C{// return to last resume}§
+
+        for ( ;; ) {                                            §\C{// general case}§
                 this->fn = fn1 + fn2;
                 fn2 = fn1;
                 fn1 = this->fn;
-                suspend(); §\C{// return to last resume}§
+                suspend();                                              §\C{// return to last resume}§
         } // for
 }
 int next( Fibonacci * this ) {
-        resume( this ); §\C{// transfer to last suspend}§
+        resume( this );                                         §\C{// transfer to last suspend}§
         return this->fn;
 }
@@ -4702 +4046 @@
         Fibonacci f1, f2;
         for ( int i = 1; i <= 10; i += 1 ) {
-                sout | next( &f1 ) | ' ' | next( &f2 );
+                sout | next( &f1 ) | ' ' | next( &f2 ) | endl;
         } // for
 }
@@ -4768 +4112 @@
                 MyThread f[4];
         }
-        sout | global.value;
+        sout | global.value | endl;
 }
 \end{cfa}
@@ -4846 +4190 @@
 void main( First * this ) {
         for ( int i = 0; i < 10; i += 1 ) {
-                sout | "First : Suspend No." | i + 1;
+                sout | "First : Suspend No." | i + 1 | endl;
                 yield();
         }
@@ -4855 +4199 @@
         wait( this->lock );
         for ( int i = 0; i < 10; i += 1 ) {
-                sout | "Second : Suspend No." | i + 1;
+                sout | "Second : Suspend No." | i + 1 | endl;
                 yield();
         }
@@ -4862 +4206 @@
 int main( void ) {
         signal_once lock;
-        sout | "User main begin";
+        sout | "User main begin" | endl;
         {
                 processor p;
@@ -4870 +4214 @@
                 }
         }
-        sout | "User main end";
+        sout | "User main end" | endl;
 }
 \end{cfa}
@@ -5567 +4911 @@
 void ?{}( Line * l ) {
         l->lnth = 0.0;
-        sout | "default";
+        sout | "default" | endl;
 }
 
@@ -5574 +4918 @@
 void ?{}( Line * l, float lnth ) {
         l->lnth = lnth;
-        sout | "lnth" | l->lnth;
+        sout | "lnth" | l->lnth | endl;
 
 }
@@ -5580 +4924 @@
 // destructor
 void ^?() {
-        sout | "destroyed";
+        sout | "destroyed" | endl;
         l.lnth = 0.0;
 }
@@ -6241 +5585 @@
 In \CFA, there are ambiguous cases with dereference and operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be interpreted as:
 \begin{cfa}
-*?§\color{red}\textvisiblespace§*? §\C{// dereference operator, dereference operator}§
-*§\color{red}\textvisiblespace§?*? §\C{// dereference, multiplication operator}§
+*?§\color{red}\textvisiblespace§*?              §\C{// dereference operator, dereference operator}§
+*§\color{red}\textvisiblespace§?*?              §\C{// dereference, multiplication operator}§
 \end{cfa}
 By default, the first interpretation is selected, which does not yield a meaningful parse.
@@ -6294 +5638 @@
 \eg:
 \begin{cfa}
-x; §\C{// int x}§
-*y; §\C{// int *y}§
-f( p1, p2 ); §\C{// int f( int p1, int p2 );}§
-g( p1, p2 ) int p1, p2; §\C{// int g( int p1, int p2 );}§
+x;                                                              §\C{// int x}§
+*y;                                                             §\C{// int *y}§
+f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
+g( p1, p2 ) int p1, p2;                 §\C{// int g( int p1, int p2 );}§
 \end{cfa}
 \CFA continues to support K\&R routine definitions:
 \begin{cfa}
-f( a, b, c ) §\C{// default int return}§
-        int a, b; char c §\C{// K\&R parameter declarations}§
+f( a, b, c )                                    §\C{// default int return}§
+        int a, b; char c                        §\C{// K\&R parameter declarations}§
 {
         ...
@@ -6321 +5665 @@
 int rtn( int i );
 int rtn( char c );
-rtn( 'x' ); §\C{// programmer expects 2nd rtn to be called}§
+rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
 \end{cfa}
 \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
 \begin{cfa}
-sout | 'x' | " " | (int)'x';
+sout | 'x' | " " | (int)'x' | endl;
 x 120
 \end{cfa}
@@ -6343 +5687 @@
 \item[Change:] make string literals ©const©:
 \begin{cfa}
-char * p = "abc"; §\C{// valid in C, deprecated in \CFA}§
-char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
+char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
+char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
 \end{cfa}
 The type of a string literal is changed from ©[] char© to ©const [] char©.
@@ -6351 +5695 @@
 \begin{cfa}
 char * p = "abc";
-p[0] = 'w'; §\C{// segment fault or change constant literal}§
+p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
 \end{cfa}
 The same problem occurs when passing a string literal to a routine that changes its argument.
@@ -6363 +5707 @@
 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
 \begin{cfa}
-int i; §\C{// forward definition}§
-int *j = ®&i®; §\C{// forward reference, valid in C, invalid in \CFA}§
-int i = 0; §\C{// definition}§
+int i;                                                  §\C{// forward definition}§
+int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
+int i = 0;                                              §\C{// definition}§
 \end{cfa}
 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
@@ -6371 +5715 @@
 \begin{cfa}
 struct X { int i; struct X *next; };
-static struct X a; §\C{// forward definition}§
+static struct X a;                              §\C{// forward definition}§
 static struct X b = { 0, ®&a® };§\C{// forward reference, valid in C, invalid in \CFA}§
-static struct X a = { 1, &b }; §\C{// definition}§
+static struct X a = { 1, &b };  §\C{// definition}§
 \end{cfa}
 \item[Rationale:] avoids having different initialization rules for builtin types and user-defined types.
@@ -6388 +5732 @@
 struct Person {
         enum ®Colour® { R, G, B };      §\C[7cm]{// nested type}§
-        struct Face { §\C{// nested type}§
-                ®Colour® Eyes, Hair; §\C{// type defined outside (1 level)}§
+        struct Face {                           §\C{// nested type}§
+                ®Colour® Eyes, Hair;    §\C{// type defined outside (1 level)}§
         };
-        ®.Colour® shirt; §\C{// type defined outside (top level)}§
-        ®Colour® pants; §\C{// type defined same level}§
-        Face looks[10]; §\C{// type defined same level}§
+        ®.Colour® shirt;                        §\C{// type defined outside (top level)}§
+        ®Colour® pants;                         §\C{// type defined same level}§
+        Face looks[10];                         §\C{// type defined same level}§
 };
-®Colour® c = R; §\C{// type/enum defined same level}§
+®Colour® c = R;                                 §\C{// type/enum defined same level}§
 Person®.Colour® pc = Person®.®R;§\C{// type/enum defined inside}§
-Person®.®Face pretty; §\C{// type defined inside}\CRT§
+Person®.®Face pretty;                   §\C{// type defined inside}\CRT§
 \end{cfa}
 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, \ie the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
@@ -6414 +5758 @@
 \item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
 \begin{cfa}
-struct Y; §\C{// struct Y and struct X are at the same scope}§
+struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
 struct X {
         struct Y { /* ... */ } y;
@@ -6429 +5773 @@
 \begin{cfa}
 void foo() {
-        int * b = malloc( sizeof(int) ); §\C{// implicitly convert void * to int *}§
-        char * c = b; §\C{// implicitly convert int * to void *, and then void * to char *}§
+        int * b = malloc( sizeof(int) );        §\C{// implicitly convert void * to int *}§
+        char * c = b;                           §\C{// implicitly convert int * to void *, and then void * to char *}§
 }
 \end{cfa}
@@ -6603 +5947 @@
 void * memalign( size_t align, size_t size );§\indexc{memalign}§
 int posix_memalign( void ** ptr, size_t align, size_t size );§\indexc{posix_memalign}§
+}
+
+// §\CFA§ safe equivalents, i.e., implicit size specification
+forall( dtype T | sized(T) ) T * malloc( void );
+forall( dtype T | sized(T) ) T * calloc( size_t dim );
+forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size );
+forall( dtype T | sized(T) ) T * memalign( size_t align );
+forall( dtype T | sized(T) ) T * aligned_alloc( size_t align );
+forall( dtype T | sized(T) ) int posix_memalign( T ** ptr, size_t align );
+
+// §\CFA§ safe general allocation, fill, resize, array
+forall( dtype T | sized(T) ) T * alloc( void );§\indexc{alloc}§
+forall( dtype T | sized(T) ) T * alloc( char fill );
+forall( dtype T | sized(T) ) T * alloc( size_t dim );
+forall( dtype T | sized(T) ) T * alloc( size_t dim, char fill );
+forall( dtype T | sized(T) ) T * alloc( T ptr[], size_t dim );
+forall( dtype T | sized(T) ) T * alloc( T ptr[], size_t dim, char fill );
+
+// §\CFA§ safe general allocation, align, fill, array
+forall( dtype T | sized(T) ) T * align_alloc( size_t align );
+forall( dtype T | sized(T) ) T * align_alloc( size_t align, char fill );
+forall( dtype T | sized(T) ) T * align_alloc( size_t align, size_t dim );
+forall( dtype T | sized(T) ) T * align_alloc( size_t align, size_t dim, char fill );
 
 // C unsafe initialization/copy
+extern "C" {
 void * memset( void * dest, int c, size_t size );
 void * memcpy( void * dest, const void * src, size_t size );
 }
 
-forall( dtype T | sized(T) ) {
-// §\CFA§ safe equivalents, i.e., implicit size specification
-        T * malloc( void );
-        T * calloc( size_t dim );
-        T * realloc( T * ptr, size_t size );
-        T * memalign( size_t align );
-        T * aligned_alloc( size_t align );
-        int posix_memalign( T ** ptr, size_t align );
-
-// §\CFA§ safe general allocation, fill, resize, array
-        T * alloc( void );§\indexc{alloc}§
-        T * alloc( char fill );
-        T * alloc( size_t dim );
-        T * alloc( size_t dim, char fill );
-        T * alloc( T ptr[], size_t dim );
-        T * alloc( T ptr[], size_t dim, char fill );
-
-// §\CFA§ safe general allocation, align, fill, array
-        T * align_alloc( size_t align );
-        T * align_alloc( size_t align, char fill );
-        T * align_alloc( size_t align, size_t dim );
-        T * align_alloc( size_t align, size_t dim, char fill );
-
 // §\CFA§ safe initialization/copy, i.e., implicit size specification
-        T * memset( T * dest, char c );§\indexc{memset}§
-        T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
+forall( dtype T | sized(T) ) T * memset( T * dest, char c );§\indexc{memset}§
+forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
 
 // §\CFA§ safe initialization/copy array
-        T * amemset( T dest[], char c, size_t dim );
-        T * amemcpy( T dest[], const T src[], size_t dim );
-}
+forall( dtype T | sized(T) ) T * memset( T dest[], size_t dim, char c );
+forall( dtype T | sized(T) ) T * memcpy( T dest[], const T src[], size_t dim );
 
 // §\CFA§ allocation/deallocation and constructor/destructor
@@ -6655 +5999 @@
 
 
-\subsection{String to Value Conversion}
+\subsection{Conversion}
 
 \leavevmode
@@ -6691 +6035 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-forall( otype T | { int ?<?( T, T ); } ) §\C{// location}§
+forall( otype T | { int ?<?( T, T ); } )        §\C{// location}§
 T * bsearch( T key, const T * arr, size_t dim );§\indexc{bsearch}§
 
-forall( otype T | { int ?<?( T, T ); } ) §\C{// position}§
+forall( otype T | { int ?<?( T, T ); } )        §\C{// position}§
 unsigned int bsearch( T key, const T * arr, size_t dim );
 
 forall( otype T | { int ?<?( T, T ); } )
 void qsort( const T * arr, size_t dim );§\indexc{qsort}§
-
-forall( otype E | { int ?<?( E, E ); } ) {
-        E * bsearch( E key, const E * vals, size_t dim );§\indexc{bsearch}§ §\C{// location}§
-        size_t bsearch( E key, const E * vals, size_t dim );§\C{// position}§
-        E * bsearchl( E key, const E * vals, size_t dim );§\indexc{bsearchl}§
-        size_t bsearchl( E key, const E * vals, size_t dim );
-        E * bsearchu( E key, const E * vals, size_t dim );§\indexc{bsearchu}§
-        size_t bsearchu( E key, const E * vals, size_t dim );
-}
-
-forall( otype K, otype E | { int ?<?( K, K ); K getKey( const E & ); } ) {
-        E * bsearch( K key, const E * vals, size_t dim );
-        size_t bsearch( K key, const E * vals, size_t dim );
-        E * bsearchl( K key, const E * vals, size_t dim );
-        size_t bsearchl( K key, const E * vals, size_t dim );
-        E * bsearchu( K key, const E * vals, size_t dim );
-        size_t bsearchu( K key, const E * vals, size_t dim );
-}
-
-forall( otype E | { int ?<?( E, E ); } ) {
-        void qsort( E * vals, size_t dim );§\indexc{qsort}§
-}
 \end{cfa}
 
@@ -6747 +6069 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-void srandom( unsigned int seed );§\indexc{srandom}§
-char random( void );§\indexc{random}§
-char random( char u ); §\C{// [0,u)}§
-char random( char l, char u ); §\C{// [l,u)}§
-int random( void );
-int random( int u ); §\C{// [0,u)}§
-int random( int l, int u ); §\C{// [l,u)}§
-unsigned int random( void );
-unsigned int random( unsigned int u ); §\C{// [0,u)}§
-unsigned int random( unsigned int l, unsigned int u ); §\C{// [l,u)}§
-long int random( void );
-long int random( long int u ); §\C{// [0,u)}§
-long int random( long int l, long int u ); §\C{// [l,u)}§
-unsigned long int random( void );
-unsigned long int random( unsigned long int u ); §\C{// [0,u)}§
-unsigned long int random( unsigned long int l, unsigned long int u ); §\C{// [l,u)}§
-float random( void );                                            §\C{// [0.0, 1.0)}§
-double random( void );                                           §\C{// [0.0, 1.0)}§
-float _Complex random( void );                           §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
-double _Complex random( void );                          §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
-long double _Complex random( void );             §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
+void rand48seed( long int s );§\indexc{rand48seed}§
+char rand48();§\indexc{rand48}§
+int rand48();
+unsigned int rand48();
+long int rand48();
+unsigned long int rand48();
+float rand48();
+double rand48();
+float _Complex rand48();
+double _Complex rand48();
+long double _Complex rand48();
 \end{cfa}
 
@@ -6810 +6122 @@
 [ int, long double ] remquo( long double, long double );
 
-float div( float, float, int * );§\indexc{div}§ §\C{// alternative name for remquo}§
+float div( float, float, int * );§\indexc{div}§ §\C{// alternative name for remquo}§
 double div( double, double, int * );
 long double div( long double, long double, int * );
@@ -6966 +6278 @@
 long double atan2( long double, long double );
 
-float atan( float, float ); §\C{// alternative name for atan2}§
+float atan( float, float );                                     §\C{// alternative name for atan2}§
 double atan( double, double );§\indexc{atan}§
 long double atan( long double, long double );
@@ -7146 +6458 @@
 
 
-\section{Time Keeping}
-\label{s:TimeKeeping}
+\section{Time}
+\label{s:TimeLib}
 
 
 %\subsection{\texorpdfstring{\protect\lstinline@Duration@}{Duration}}
-\subsection{\texorpdfstring{\LstBasicStyle{Duration}}{Duration}}
+\subsection{\texorpdfstring{\LstKeywordStyle{\textmd{Duration}}}{Duration}}
 \label{s:Duration}
 
@@ -7157 +6469 @@
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 struct Duration {
-        int64_t tv; §\C{// nanoseconds}§
+        int64_t tv;                                                     §\C{// nanoseconds}§
 };
 
@@ -7200 +6512 @@
 
 Duration abs( Duration rhs );
+
+forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Duration dur );
 
 Duration ?`ns( int64_t nsec );
@@ -7223 +6537 @@
 int64_t ?`d( Duration dur );
 int64_t ?`w( Duration dur );
-
-Duration max( Duration lhs, Duration rhs );
-Duration min( Duration lhs, Duration rhs );
 \end{cfa}
 
 
 %\subsection{\texorpdfstring{\protect\lstinline@\timeval@}{timeval}}
-\subsection{\texorpdfstring{\LstBasicStyle{timeval}}{timeval}}
+\subsection{\texorpdfstring{\LstKeywordStyle{\textmd{timeval}}}{timeval}}
 \label{s:timeval}
 
@@ -7249 +6560 @@
 
 
-%\subsection{\texorpdfstring{\protect\lstinline@timespec@}{timespec}}
-\subsection{\texorpdfstring{\LstBasicStyle{timespec}}{timespec}}
+\subsection{\texorpdfstring{\protect\lstinline@timespec@}{timespec}}
 \label{s:timespec}
 
@@ -7269 +6579 @@
 
 
-%\subsection{\texorpdfstring{\protect\lstinline@itimerval@}{itimerval}}
-\subsection{\texorpdfstring{\LstBasicStyle{itimerval}}{itimerval}}
+\subsection{\texorpdfstring{\protect\lstinline@itimerval@}{itimerval}}
 \label{s:itimerval}
 
@@ -7280 +6589 @@
 
 
-%\subsection{\texorpdfstring{\protect\lstinline@Time@}{Time}}
-\subsection{\texorpdfstring{\LstBasicStyle{Time}}{Time}}
+\subsection{\texorpdfstring{\protect\lstinline@Time@}{Time}}
 \label{s:Time}
 
@@ -7287 +6595 @@
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 struct Time {
-        uint64_t tv; §\C{// nanoseconds since UNIX epoch}§
+        uint64_t tv;                                            §\C{// nanoseconds since UNIX epoch}§
 };
 
 void ?{}( Time & time );
 void ?{}( Time & time, zero_t );
-
+void ?{}( Time & time, int year, int month = 0, int day = 0, int hour = 0, int min = 0, int sec = 0, int nsec = 0 );
 Time ?=?( Time & time, zero_t );
 
@@ -7301 +6609 @@
 Time ?=?( Time & time, timespec t );
 
-Time ?+?( Time & lhs, Duration rhs );
-Time ?+?( Duration lhs, Time rhs );
-Time ?+=?( Time & lhs, Duration rhs );
-
-Duration ?-?( Time lhs, Time rhs );
-Time ?-?( Time lhs, Duration rhs );
-Time ?-=?( Time & lhs, Duration rhs );
-_Bool ?==?( Time lhs, Time rhs );
-_Bool ?!=?( Time lhs, Time rhs );
-_Bool ?<?( Time lhs, Time rhs );
-_Bool ?<=?( Time lhs, Time rhs );
-_Bool ?>?( Time lhs, Time rhs );
-_Bool ?>=?( Time lhs, Time rhs );
+Time ?+?( Time & lhs, Duration rhs ) { return (Time)@{ lhs.tv + rhs.tv }; }
+Time ?+?( Duration lhs, Time rhs ) { return rhs + lhs; }
+Time ?+=?( Time & lhs, Duration rhs ) { lhs = lhs + rhs; return lhs; }
+
+Duration ?-?( Time lhs, Time rhs ) { return (Duration)@{ lhs.tv - rhs.tv }; }
+Time ?-?( Time lhs, Duration rhs ) { return (Time)@{ lhs.tv - rhs.tv }; }
+Time ?-=?( Time & lhs, Duration rhs ) { lhs = lhs - rhs; return lhs; }
+_Bool ?==?( Time lhs, Time rhs ) { return lhs.tv == rhs.tv; }
+_Bool ?!=?( Time lhs, Time rhs ) { return lhs.tv != rhs.tv; }
+_Bool ?<?( Time lhs, Time rhs ) { return lhs.tv < rhs.tv; }
+_Bool ?<=?( Time lhs, Time rhs ) { return lhs.tv <= rhs.tv; }
+_Bool ?>?( Time lhs, Time rhs ) { return lhs.tv > rhs.tv; }
+_Bool ?>=?( Time lhs, Time rhs ) { return lhs.tv >= rhs.tv; }
+
+forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Time time );
 
 char * yy_mm_dd( Time time, char * buf );
@@ -7331 +6641 @@
 
 size_t strftime( char * buf, size_t size, const char * fmt, Time time );
-forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Time time );
 \end{cfa}
 
@@ -7352 +6661 @@
 
 %\subsection{\texorpdfstring{\protect\lstinline@Clock@}{Clock}}
-\subsection{\texorpdfstring{\LstBasicStyle{Clock}}{Clock}}
+\subsection{\texorpdfstring{\LstKeywordStyle{\textmd{Clock}}}{Clock}}
 \label{s:Clock}
 
@@ -7358 +6667 @@
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 struct Clock {
-        Duration offset; §\C{// for virtual clock: contains offset from real-time}§
-        int clocktype; §\C{// implementation only -1 (virtual), CLOCK\_REALTIME}§
+        Duration offset;                                        §\C{// for virtual clock: contains offset from real-time}§
+        int clocktype;                                          §\C{// implementation only -1 (virtual), CLOCK\_REALTIME}§
 };
 
@@ -7366 +6675 @@
 void ?{}( Clock & clk );
 void ?{}( Clock & clk, Duration adj );
-
-Duration getResNsec(); §\C{// with nanoseconds}§
-Duration getRes(); §\C{// without nanoseconds}§
-
-Time getTimeNsec(); §\C{// with nanoseconds}§
-Time getTime(); §\C{// without nanoseconds}§
+Duration getRes();
+Time getTimeNsec();                                             §\C{// with nanoseconds}§
+Time getTime();                                                 §\C{// without nanoseconds}§
 Time getTime( Clock & clk );
 Time ?()( Clock & clk );
@@ -7387 +6693 @@
 
 \begin{cfa}
-void ?{}( Int * this ); §\C{// constructor/destructor}§
+void ?{}( Int * this );                                 §\C{// constructor/destructor}§
 void ?{}( Int * this, Int init );
 void ?{}( Int * this, zero_t );
@@ -7396 +6702 @@
 void ^?{}( Int * this );
 
-Int ?=?( Int * lhs, Int rhs ); §\C{// assignment}§
+Int ?=?( Int * lhs, Int rhs );                  §\C{// assignment}§
 Int ?=?( Int * lhs, long int rhs );
 Int ?=?( Int * lhs, unsigned long int rhs );
@@ -7413 +6719 @@
 unsigned long int narrow( Int val );
 
-int ?==?( Int oper1, Int oper2 ); §\C{// comparison}§
+int ?==?( Int oper1, Int oper2 );               §\C{// comparison}§
 int ?==?( Int oper1, long int oper2 );
 int ?==?( long int oper2, Int oper1 );
@@ -7449 +6755 @@
 int ?>=?( unsigned long int oper1, Int oper2 );
 
-Int +?( Int oper ); §\C{// arithmetic}§
+Int +?( Int oper );                                             §\C{// arithmetic}§
 Int -?( Int oper );
 Int ~?( Int oper );
@@ -7531 +6837 @@
 Int ?>>=?( Int * lhs, mp_bitcnt_t shift );
 
-Int abs( Int oper ); §\C{// number functions}§
+Int abs( Int oper );                                    §\C{// number functions}§
 Int fact( unsigned long int N );
 Int gcd( Int oper1, Int oper2 );
@@ -7556 +6862 @@
 #include <gmp>§\indexc{gmp}§
 int main( void ) {
-        sout | "Factorial Numbers";
+        sout | "Factorial Numbers" | endl;
         Int fact = 1;
 
-        sout | 0 | fact;
+        sout | 0 | fact | endl;
         for ( unsigned int i = 1; i <= 40; i += 1 ) {
                 fact *= i;
-                sout | i | fact;
+                sout | i | fact | endl;
         }
 }
@@ -7642 +6948 @@
 // implementation
 struct Rational {§\indexc{Rational}§
-        long int numerator, denominator; §\C{// invariant: denominator > 0}§
+        long int numerator, denominator;        §\C{// invariant: denominator > 0}§
 }; // Rational
 
-Rational rational(); §\C{// constructors}§
+Rational rational();                                    §\C{// constructors}§
 Rational rational( long int n );
 Rational rational( long int n, long int d );
@@ -7651 +6957 @@
 void ?{}( Rational * r, one_t );
 
-long int numerator( Rational r ); §\C{// numerator/denominator getter/setter}§
+long int numerator( Rational r );               §\C{// numerator/denominator getter/setter}§
 long int numerator( Rational r, long int n );
 long int denominator( Rational r );
 long int denominator( Rational r, long int d );
 
-int ?==?( Rational l, Rational r ); §\C{// comparison}§
+int ?==?( Rational l, Rational r );             §\C{// comparison}§
 int ?!=?( Rational l, Rational r );
 int ?<?( Rational l, Rational r );
@@ -7663 +6969 @@
 int ?>=?( Rational l, Rational r );
 
-Rational -?( Rational r ); §\C{// arithmetic}§
+Rational -?( Rational r );                              §\C{// arithmetic}§
 Rational ?+?( Rational l, Rational r );
 Rational ?-?( Rational l, Rational r );
@@ -7669 +6975 @@
 Rational ?/?( Rational l, Rational r );
 
-double widen( Rational r ); §\C{// conversion}§
+double widen( Rational r );                             §\C{// conversion}§
 Rational narrow( double f, long int md );