Changeset 95b3a9c for doc/user/user.tex

Timestamp:

Feb 17, 2021, 12:45:36 PM (3 years ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum

Children:

e7c077a

Parents:

5e99a9a (diff), 9fb1367 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.

Message:

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

File:

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

doc/user/user.tex

@@ -11 +11 @@
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
-%% Last Modified On : Mon Oct  5 08:57:29 2020
-%% Update Count     : 3998
+%% Last Modified On : Mon Feb 15 13:48:53 2021
+%% Update Count     : 4452
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -37 +37 @@
 \usepackage{mathptmx}                                   % better math font with "times"
 \usepackage[usenames]{color}
+\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
+\usepackage{breakurl}
+
+\renewcommand\footnoterule{\kern -3pt\rule{0.3\linewidth}{0.15pt}\kern 2pt}
+
+\usepackage[pagewise]{lineno}
+\renewcommand{\linenumberfont}{\scriptsize\sffamily}
+\usepackage[firstpage]{draftwatermark}
+\SetWatermarkLightness{0.9}
+
+% Default underscore is too low and wide. Cannot use lstlisting "literate" as replacing underscore
+% removes it as a variable-name character so keywords in variables are highlighted. MUST APPEAR
+% AFTER HYPERREF.
+\renewcommand{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.075ex}}}
+
+\setlength{\topmargin}{-0.45in}                                                 % move running title into header
+\setlength{\headsep}{0.25in}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 \newcommand{\CFALatin}{}
 % inline code ©...© (copyright symbol) emacs: C-q M-)
@@ -46 +66 @@
 % math escape $...$ (dollar symbol)
 \input{common}                                          % common CFA document macros
-\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
-\usepackage{breakurl}
-
-\renewcommand\footnoterule{\kern -3pt\rule{0.3\linewidth}{0.15pt}\kern 2pt}
-
-\usepackage[pagewise]{lineno}
-\renewcommand{\linenumberfont}{\scriptsize\sffamily}
-\usepackage[firstpage]{draftwatermark}
-\SetWatermarkLightness{0.9}
-
-% Default underscore is too low and wide. Cannot use lstlisting "literate" as replacing underscore
-% removes it as a variable-name character so keywords in variables are highlighted. MUST APPEAR
-% AFTER HYPERREF.
-\renewcommand{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.075ex}}}
-
-\setlength{\topmargin}{-0.45in}                                                 % move running title into header
-\setlength{\headsep}{0.25in}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
 \CFAStyle                                                                                               % use default CFA format-style
+\lstset{language=CFA}                                                                   % CFA default lnaguage
 \lstnewenvironment{C++}[1][]                            % use C++ style
-{\lstset{language=C++,moredelim=**[is][\protect\color{red}]{®}{®},#1}}
+{\lstset{language=C++,moredelim=**[is][\protect\color{red}]{@}{@},#1}}
 {}
 
@@ -81 +82 @@
 \newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
 \newcommand{\R}[1]{\Textbf{#1}}
+\newcommand{\RC}[1]{\Textbf{\LstBasicStyle{#1}}}
 \newcommand{\B}[1]{{\Textbf[blue]{#1}}}
 \newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
@@ -103 +105 @@
 
 \author{
-\huge \CFA Team \medskip \\
-\Large Andrew Beach, Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\
-\Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Rob Schluntz
+\huge \CFA Team (past and present) \medskip \\
+\Large Andrew Beach, Richard Bilson, Michael Brooks, Peter A. Buhr, Thierry Delisle, \smallskip \\
+\Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Colby Parsons, Rob Schluntz, \smallskip \\
+\Large Fangren Yu, Mubeen Zulfiqar
 }% author
 
@@ -126 +129 @@
 \vspace*{\fill}
 \noindent
-\copyright\,2016 \CFA Project \\ \\
+\copyright\,2016, 2018, 2021 \CFA Project \\ \\
 \noindent
 This work is licensed under the Creative Commons Attribution 4.0 International License.
@@ -144 +147 @@
 \section{Introduction}
 
-\CFA{}\index{cforall@\CFA}\footnote{Pronounced ``\Index*{C-for-all}'', and written \CFA, CFA, or \CFL.} is a modern general-purpose programming-language, designed as an evolutionary step forward for the C programming language.
+\CFA{}\index{cforall@\CFA}\footnote{Pronounced ``\Index*{C-for-all}'', and written \CFA, CFA, or \CFL.} is a modern general-purpose concurrent programming-language, designed as an evolutionary step forward for the C programming language.
 The syntax of \CFA builds from C and should look immediately familiar to C/\Index*[C++]{\CC{}} programmers.
 % Any language feature that is not described here can be assumed to be using the standard \Celeven syntax.
-\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.
+\CFA adds many modern 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.
@@ -157 +160 @@
 instead, a programmer evolves a legacy program into \CFA by incrementally incorporating \CFA features.
 As well, new programs can be written in \CFA using a combination of C and \CFA features.
+In many ways, \CFA is to C as \Index{Scala}~\cite{Scala} is to Java, providing a vehicle for new typing and control-flow capabilities on top of a highly popular programming language allowing immediate dissemination.
 
 \Index*[C++]{\CC{}}~\cite{c++:v1} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
@@ -165 +169 @@
 For example, the following programs compare the C, \CFA, and \CC I/O mechanisms, where the programs output the same result.
 \begin{center}
-\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}}      \\
-\begin{cfa}
-#include <stdio.h>§\indexc{stdio.h}§
+\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
+\multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}}   & \multicolumn{1}{c}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{\CC}}      \\
+\begin{cfa}
+#include <stdio.h>$\indexc{stdio.h}$
 
 int main( void ) {
         int x = 0, y = 1, z = 2;
-        ®printf( "%d %d %d\n", x, y, z );®
+        @printf( "%d %d %d\n", x, y, z );@
 }
 \end{cfa}
 &
 \begin{cfa}
-#include <fstream>§\indexc{fstream}§
+#include <fstream>$\indexc{fstream}$
 
 int main( void ) {
         int x = 0, y = 1, z = 2;
-        ®sout | x | y | z;®§\indexc{sout}§
+        @sout | x | y | z;@$\indexc{sout}$
 }
 \end{cfa}
 &
 \begin{cfa}
-#include <iostream>§\indexc{iostream}§
+#include <iostream>$\indexc{iostream}$
 using namespace std;
 int main() {
         int x = 0, y = 1, z = 2;
-        ®cout<<x<<" "<<y<<" "<<z<<endl;®
+        @cout<<x<<" "<<y<<" "<<z<<endl;@
 }
 \end{cfa}
 \end{tabular}
 \end{center}
-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}).
+While \CFA I/O \see{\VRef{s:StreamIOLibrary}} looks similar to \Index*[C++]{\CC{}}, there are important differences, such as automatic spacing between variables and an implicit newline at the end of the expression list, similar to \Index*{Python}~\cite{Python}.
 
 
@@ -210 +214 @@
 \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 billions of lines of code implementing everything from hobby projects to commercial operating-systems.
 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 February 2020 ranks the top six most \emph{popular} programming languages as \Index*{Java} 17.4\%, C 16.8\%, Python 9.3\%, \Index*[C++]{\CC{}} 6.2\%, \Csharp 5.9\%, Visual Basic 5.9\% = 61.5\%, where the next 50 languages are less than 2\% each, with a long tail.
+For system programming, where direct access to hardware, storage management, and real-time issues are a requirement, C is the only language of choice.
+The TIOBE index~\cite{TIOBE} for February 2021 ranks the top six most \emph{popular} programming languages as C 17.4\%, \Index*{Java} 12\%, Python 12\%, \Index*[C++]{\CC{}} 7.6\%, \Csharp 4\%, Visual Basic 3.8\% = 56.8\%, where the next 50 languages are less than 2\% each, with a long tail.
 The top 4 rankings over the past 35 years are:
 \begin{center}
 \setlength{\tabcolsep}{10pt}
 \begin{tabular}{@{}rcccccccc@{}}
-                & 2020  & 2015  & 2010  & 2005  & 2000  & 1995  & 1990  & 1985  \\ \hline
-Java    & 1             & 2             & 1             & 2             & 3             & -             & -             & -             \\
-\R{C}   & \R{2} & \R{1} & \R{2} & \R{1} & \R{1} & \R{2} & \R{1} & \R{1} \\
-Python  & 3             & 7             & 6             & 6             & 22    & 21    & -             & -             \\
-\CC             & 4             & 4             & 4             & 3             & 2             & 1             & 2             & 12    \\
+                & 2021  & 2016  & 2011  & 2006  & 2001  & 1996  & 1991  & 1986  \\ \hline
+\R{C}   & \R{1} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} & \R{1} & \R{1} \\
+Java    & 2             & 1             & 1             & 2             & 3             & 28    & -             & -             \\
+Python  & 3             & 5             & 6             & 7             & 23    & 13    & -             & -             \\
+\CC             & 4             & 3             & 3             & 3             & 2             & 2             & 2             & 8             \\
 \end{tabular}
 \end{center}
@@ -232 +236 @@
 As stated, the goal of the \CFA project is to engineer modern language-features into C in an evolutionary rather than revolutionary way.
 \CC~\cite{C++14,C++} is an example of a similar project;
-however, it largely extended the C language, and did not address most of C's existing problems.\footnote{%
+however, it largely extended the C language, and did not address many of C's existing problems.\footnote{%
 Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.}
 \Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language-features (\eg objects, concurrency) are added and problems fixed within the framework of the existing language.
@@ -241 +245 @@
 
 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;
-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.
+To achieve these goals required a significant engineering exercise, \ie ``thinking \emph{inside} the C box''.
+Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern language.
 While \Index*[C11]{\Celeven{}} made a few simple extensions to the language, nothing was added to address existing problems in the language or to augment the language with modern language-features.
 While some may argue that modern language-features may make C complex and inefficient, it is clear a language without modern capabilities is insufficient for the advanced programming problems existing today.
@@ -251 +253 @@
 \section{History}
 
-The \CFA project started with \Index*{Dave Till}\index{Till, Dave}'s \Index*{K-W C}~\cite{Buhr94a,Till89}, which extended C with new declaration syntax, multiple return values from routines, and advanced assignment capabilities using the notion of tuples.
-(See~\cite{Werther96} for similar work in \Index*[C++]{\CC{}}.)
+The \CFA project started with \Index*{Dave Till}\index{Till, Dave}'s \Index*{K-W C}~\cite{Buhr94a,Till89}, which extended C with new declaration syntax, multiple return values from routines, and advanced assignment capabilities using the notion of tuples \see{\cite{Werther96} for similar work in \Index*[C++]{\CC{}}}.
 The first \CFA implementation of these extensions was by \Index*{Rodolfo Esteves}\index{Esteves, Rodolfo}~\cite{Esteves04}.
 
 The signature feature of \CFA is \emph{\Index{overload}able} \Index{parametric-polymorphic} functions~\cite{forceone:impl,Cormack90,Duggan96} with functions generalized using a ©forall© clause (giving the language its name):
 \begin{cfa}
-®forall( otype T )® T identity( T val ) { return val; }
-int forty_two = identity( 42 ); §\C{// T is bound to int, forty\_two == 42}§
+@forall( otype T )@ T identity( T val ) { return val; }
+int forty_two = identity( 42 ); $\C{// T is bound to int, forty\_two == 42}$
 \end{cfa}
 % extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC{}} approach of object-oriented extensions.
 \CFA{}\hspace{1pt}'s polymorphism was originally formalized by \Index*{Glen Ditchfield}\index{Ditchfield, Glen}~\cite{Ditchfield92}, and first implemented by \Index*{Richard Bilson}\index{Bilson, Richard}~\cite{Bilson03}.
 However, at that time, there was little interesting in extending C, so work did not continue.
-As the saying goes, ``\Index*{What goes around, comes around.}'', and there is now renewed interest in the C programming language because of legacy code-bases, so the \CFA project has been restarted.
+As the saying goes, ``\Index*{What goes around, comes around.}'', and there is now renewed interest in the C programming language because of the legacy code-base, so the \CFA project was restarted in 2015.
 
 
@@ -273 +274 @@
 This feature allows \CFA programmers to take advantage of the existing panoply of C libraries to access thousands of external software features.
 Language developers often state that adequate \Index{library support} takes more work than designing and implementing the language itself.
-Fortunately, \CFA, like \Index*[C++]{\CC{}}, starts with immediate access to all exiting C libraries, and in many cases, can easily wrap library routines with simpler and safer interfaces, at very low cost.
+Fortunately, \CFA, like \Index*[C++]{\CC{}}, starts with immediate access to all exiting C libraries, and in many cases, can easily wrap library routines with simpler and safer interfaces, at zero or very low cost.
 Hence, \CFA begins by leveraging the large repository of C libraries, and than allows programmers to incrementally augment their C programs with modern \Index{backward-compatible} features.
 
@@ -286 +287 @@
 
 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{cfa}
 which can be augmented simply with a polymorphic, type-safe, \CFA-overloaded wrappers:
@@ -295 +296 @@
 
 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{cfa}
@@ -310 +311 @@
 \begin{cfa}
 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();
@@ -319 +320 @@
 However, it is necessary to differentiate between C and \CFA code because of name \Index{overload}ing, as for \CC.
 For example, the C math-library provides the following routines for computing the absolute value of the basic types: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©.
-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 );
-\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.
-
-This example strongly illustrates a core idea in \CFA: \emph{the \Index{power of a name}}.
+Whereas, \CFA wraps each of these routines into one 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 );
+\end{cfa}
+The problem is \Index{name clash} between the C name ©abs© and the \CFA names ©abs©, resulting in two name linkages\index{C linkage}: ©extern "C"© and ©extern "Cforall"© (default).
+Overloaded names must use \newterm{name mangling}\index{mangling!name} to create unique names that are different from unmangled C names.
+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.
+The only way around this problem is C's approach of creating unique names for each pairing of operation and type.
+
+This example illustrates a core idea in \CFA: \emph{the \Index{power of a name}}.
 The name ``©abs©'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
 Hence, knowing the name ©abs© is sufficient to apply it to any type where it is applicable.
@@ -344 +344 @@
 
 
-\section[Compiling a CFA Program]{Compiling a \CFA Program}
+\section{\CFA Compilation}
 
 The command ©cfa© is used to compile a \CFA program and is based on the \Index{GNU} \Indexc{gcc} command, \eg:
 \begin{cfa}
-cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] [ C/§\CFA{}§ source-files ] [ assembler/loader files ]
-\end{cfa}
-\CFA programs having the following ©gcc© flags turned on:
-\begin{description}
+cfa$\indexc{cfa}\index{compilation!cfa@©cfa©}$ [ gcc/$\CFA{}$-options ] [ C/$\CFA{}$ source-files ] [ assembler/loader files ]
+\end{cfa}
+There is no ordering among options (flags) and files, unless an option has an argument, which must appear immediately after the option possibly with or without a space separating option and argument.
+
+\CFA has the following ©gcc© flags turned on:
+\begin{description}[topsep=0pt]
 \item
 \Indexc{-std=gnu11}\index{compilation option!-std=gnu11@{©-std=gnu11©}}
@@ -359 +361 @@
 Use the traditional GNU semantics for inline routines in C11 mode, which allows inline routines in header files.
 \end{description}
-The following new \CFA options are available:
-\begin{description}
+
+\CFA has the following new options:
+\begin{description}[topsep=0pt]
 \item
 \Indexc{-CFA}\index{compilation option!-CFA@©-CFA©}
-Only the C preprocessor and the \CFA translator steps are performed and the transformed program is written to standard output, which makes it possible to examine the code generated by the \CFA translator.
+Only the C preprocessor (flag ©-E©) and the \CFA translator steps are performed and the transformed program is written to standard output, which makes it possible to examine the code generated by the \CFA translator.
 The generated code starts with the standard \CFA \Index{prelude}.
+
+\item
+\Indexc{-XCFA}\index{compilation option!-XCFA@©-XCFA©}
+Pass next flag as-is to the ©cfa-cpp© translator (see details below).
 
 \item
 \Indexc{-debug}\index{compilation option!-debug@©-debug©}
 The program is linked with the debugging version of the runtime system.
-The debug version performs runtime checks to help during the debugging phase of a \CFA program, but can substantially slow program execution.
+The debug version performs runtime checks to aid the debugging phase of a \CFA program, but can substantially slow program execution.
 The runtime checks should only be removed after the program is completely debugged.
 \textbf{This option is the default.}
@@ -399 +406 @@
 \item
 \Indexc{-no-include-stdhdr}\index{compilation option!-no-include-stdhdr@©-no-include-stdhdr©}
-Do not supply ©extern "C"© wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}).
+Do not supply ©extern "C"© wrappers for \Celeven standard include files \see{\VRef{s:StandardHeaders}}.
 \textbf{This option is \emph{not} the default.}
 \end{comment}
@@ -430 +437 @@
 \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}
@@ -438 +445 @@
 
 The \CFA translator has multiple steps.
-The following flags control how the tranlator works, the stages run, and printing within a stage.
+The following flags control how the translator 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.
+Each option must be escaped with \Indexc{-XCFA}\index{translator option!-XCFA@{©-XCFA©}} to direct it to the compiler step, similar to the ©-Xlinker© flag for the linker, \eg:
+\begin{lstlisting}[language=sh]
+cfa $test$.cfa -CFA -XCFA -p # print translated code without printing the standard prelude
+cfa $test$.cfa -XCFA -P -XCFA parse -XCFA -n # show program parse without prelude
+\end{lstlisting}
 \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
+\Indexc{-c}\index{translator option!-c@{©-c©}}, \Indexc{--colors}\index{translator option!--colors@{©--colors©}} \, diagnostic color: ©never©, ©always©, \lstinline[deletekeywords=auto]{auto}
+\item
+\Indexc{-g}\index{translator option!-g@{©-g©}}, \Indexc{--gdb}\index{translator option!--gdb@{©--gdb©}} \, wait for gdb to attach
+\item
+\Indexc{-h}\index{translator option!-h@{©-h©}}, \Indexc{--help}\index{translator option!--help@{©--help©}} \, print translator 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
@@ -454 +470 @@
 \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
+\Indexc{-p}\index{translator option!-p@{©-p©}}, \Indexc{--prototypes}\index{translator option!--prototypes@{©--prototypes©}} \, do not generate prelude prototypes $\Rightarrow$ prelude not printed
+\item
+\Indexc{-d}\index{translator option!-d@{©-d©}}, \Indexc{--deterministic-out}\index{translator option!--deterministic-out@{©--deterministic-out©}} \, only print deterministic output
 \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{ascodegen}\index{translator option!-P@{©-P©}!©ascodegen©}\index{translator option!--print@{©-print©}!©ascodegen©} \, as codegen rather than AST
+\item
+\Indexc{asterr}\index{translator option!-P@{©-P©}!©asterr©}\index{translator option!--print@{©-print©}!©asterr©} \, AST on error
+\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{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{tree}\index{translator option!-P@{©-P©}!©tree©}\index{translator option!--print@{©-print©}!©tree©} \, parse tree
+\item
+\Indexc{ast}\index{translator option!-P@{©-P©}!©ast©}\index{translator option!--print@{©-print©}!©ast©} \, AST after parsing
+\item
+\Indexc{symevt}\index{translator option!-P@{©-P©}!©symevt©}\index{translator option!--print@{©-print©}!©symevt©} \, symbol table events
+\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
+\Indexc{resolver}\index{translator option!-P@{©-P©}!©resolver©}\index{translator option!--print@{©-print©}!©resolver©} \, before resolver step
 \item
 \Indexc{astexpr}\index{translator option!-P@{©-P©}!©astexpr©}\index{translator option!--print@{©-print©}!©altexpr©} \, AST after expression analysis
 \item
+\Indexc{ctordtor}\index{translator option!-P@{©-P©}!©ctordtor©}\index{translator option!--print@{©-print©}!©ctordtor©} \, after ctor/dtor are replaced
+\item
+\Indexc{tuple}\index{translator option!-P@{©-P©}!©tuple©}\index{translator option!--print@{©-print©}!©tuple©} \, after tuple expansion
+\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}
+\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: ©counters©, ©heap©, ©time©, ©all©, ©none©
 \item
 \Indexc{-t}\index{translator option!-t@{©-t©}}, \Indexc{--tree}\index{translator option!--tree@{©--tree©}} build in tree
@@ -513 +527 @@
 \label{s:BackquoteIdentifiers}
 
-\CFA introduces several new keywords (see \VRef{s:CFAKeywords}) that can clash with existing C variable-names in legacy code.
+\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;
+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©.
+\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.
 
@@ -527 +541 @@
 \begin{cfa}
 // include file uses the CFA keyword "with".
-#if ! defined( with ) §\C{// nesting ?}§
-#define with ®``®with §\C{// make keyword an identifier}§
+#if ! defined( with )                                                   $\C{// nesting ?}$
+#define with @``@with                                                   $\C{// make keyword an identifier}$
 #define __CFA_BFD_H__
 #endif
-§{\color{red}\#\textbf{include\_next} <bfdlink.h>}§ §\C{// must have internal check for multiple expansion}§
-#if defined( with ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§
+$\R{\#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__
@@ -544 +558 @@
 \section{Constant Underscores}
 
-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}§
+Numeric constants are extended to allow \Index{underscore}s\index{constant!underscore} as a separator, \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}$
 \end{cfa}
 The rules for placement of underscores are:
@@ -574 +588 @@
 It is significantly easier to read and enter long constants when they are broken up into smaller groupings (many cultures use comma and/or period among digits for the same purpose).
 This extension is backwards compatible, matches with the use of underscore in variable names, and appears in \Index*{Ada} and \Index*{Java} 8.
+\CC uses the single quote (©'©) as a separator, restricted within a sequence of digits, \eg ©0xaa©©'©©ff©, ©3.141©©'©©592E1©©'©©1©.
 
 
 \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(x,y)}, 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$.
-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)©.
+C, \CC, and Java (and other programming languages) have no exponentiation operator\index{exponentiation!operator}\index{operator!exponentiation}, \ie $x^y$, and instead use a routine, like \Indexc{pow(x,y)}, to perform the exponentiation operation.
+\CFA extends the basic operators with the exponentiation operator ©?©\R{©\\©}©?©\index{?\\?@©?@\@?©} and ©?©\R{©\\©}©=?©\index{?\\=?@©@\@=?©}, as in, ©x ©\R{©\\©}© y© and ©x ©\R{©\\©}©= 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©.
 
 There are exponentiation operators for integral and floating types, including the builtin \Index{complex} types.
@@ -587 +602 @@
 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
+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©.
+Because exponentiation has higher priority than ©+©, parenthesis are necessary for exponentiation of \Index{complex constant}s or the expression is parsed as ©1.0f+©\R{©(©}©2.0fi \ 3.0f©\R{©)©}©+2.0fi©, requiring \R{©(©}©1.0f+2.0fi©\R{©)©}© \ ©\R{©(©}©3.0f+2.0fi©\R{©)©}.
+
 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 );
+forall( otype T | { void ?{}( T & this, one_t ); T ?*?( T, T ); } )
+T ?@\@?( T ep, unsigned int y );
+forall( otype T | { void ?{}( T & this, one_t ); T ?*?( T, T ); } )
+T ?@\@?( T ep, unsigned long int y );
 \end{cfa}
 The user type ©T© must define multiplication, one (©1©), and ©*©.
@@ -609 +625 @@
 
 %\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{\texorpdfstring{\LstKeywordStyle{if} / \LstKeywordStyle{while} Statement}{if / while Statement}}
+
+The ©if©/©while© expression allows declarations, similar to ©for© declaration expression.\footnote{
+Declarations in the ©do©-©while© condition are not useful because they appear after the loop body.}
+\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.
+The scope of the declaration(s) is local to the ©if© statement but exist within both the \emph{then} and \emph{else} clauses.
+\CC only provides a single declaration always compared ©!=© to 0.
 
 
 %\section{\texorpdfstring{\protect\lstinline@case@ Clause}{case Clause}}
 \subsection{\texorpdfstring{\LstKeywordStyle{case} Clause}{case Clause}}
+\label{s:caseClause}
 
 C restricts the ©case© clause of a ©switch© statement to a single value.
@@ -640 +658 @@
 \begin{cfa}
 switch ( i ) {
-  case ®1, 3, 5®:
+  case @1, 3, 5@:
         ...
-  case ®2, 4, 6®:
+  case @2, 4, 6@:
         ...
 }
@@ -670 +688 @@
 \begin{cfa}
 switch ( i ) {
-  case ®1~5:® §\C{// 1, 2, 3, 4, 5}§
+  case @1~5:@ $\C{// 1, 2, 3, 4, 5}$
         ...
-  case ®10~15:® §\C{// 10, 11, 12, 13, 14, 15}§
+  case @10~15:@ $\C{// 10, 11, 12, 13, 14, 15}$
         ...
 }
@@ -678 +696 @@
 Lists of subranges are also allowed.
 \begin{cfa}
-case ®1~5, 12~21, 35~42®:
+case @1~5, 12~21, 35~42@:
 \end{cfa}
 
@@ -722 +740 @@
 if ( argc == 3 ) {
         // open output file
-        ®// open input file
-®} else if ( argc == 2 ) {
-        ®// open input file (duplicate)
-
-®} else {
+        @// open input file
+@} else if ( argc == 2 ) {
+        @// open input file (duplicate)
+
+@} else {
         // usage message
 }
@@ -733 +751 @@
 \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.
+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
+  @case 1: case 3: case 5:@     // odd values
         // odd action
         break;
-  ®case 2: case 4: case 6:®     // even values
+  @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.
+This situation better handled without fall-through by allowing a list of case values \see{\VRef{s:caseClause}}.
+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 most 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.
 
@@ -756 +774 @@
         if ( j < k ) {
                 ...
-          ®case 1:®             // transfer into "if" statement
+          @case 1:@             // transfer into "if" statement
                 ...
         } // if
@@ -762 +780 @@
         while ( j < 5 ) {
                 ...
-          ®case 3:®             // transfer into "while" statement
+          @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.
+This usage branches into control structures, which is known to cause both comprehension and technical difficulties.
+The comprehension problem results 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.
+There are few 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}
@@ -794 +812 @@
 \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.
+Most 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.
@@ -803 +821 @@
 \begin{cfa}
 switch ( x ) {
-        ®int y = 1;® §\C{// unreachable initialization}§
-        ®x = 7;® §\C{// unreachable code without label/branch}§
+        @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}§
+        @int z = 0;@ $\C{// unreachable initialization, cannot appear after case}$
         z = 2;
   case 1:
-        ®x = z;® §\C{// without fall through, z is uninitialized}§
+        @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.
+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©, where both 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 a control structure, \ie there are multiple entry points into its statement body.
 \end{enumerate}
 
@@ -842 +860 @@
 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 ) {
+@choose@ ( i ) {
   case 1:  case 2:  case 3:
         ...
-        ®// implicit end of switch (break)
-  ®case 5:
+        @// implicit end of switch (break)
+  @case 5:
         ...
-        ®fallthru®; §\C{// explicit fall through}§
+        @fallthru@; $\C{// explicit fall through}$
   case 7:
         ...
-        ®break® §\C{// explicit end of switch (redundant)}§
+        @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;
+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.
@@ -872 +890 @@
 \begin{cfa}
 switch ( x ) {
-        ®int i = 0;® §\C{// allowed only at start}§
+        @int i = 0;@ $\C{// allowed only at start}$
   case 0:
         ...
-        ®int j = 0;® §\C{// disallowed}§
+        @int j = 0;@ $\C{// disallowed}$
   case 1:
         {
-                ®int k = 0;® §\C{// allowed at different nesting levels}§
+                @int k = 0;@ $\C{// allowed at different nesting levels}$
                 ...
-          ®case 2:® §\C{// disallow case in nested statements}§
+          @case 2:@ $\C{// disallow case in nested statements}$
         }
   ...
@@ -897 +915 @@
   case 3:
         if ( ... ) {
-                ... ®fallthru;® // goto case 4
+                ... @fallthru;@ // goto case 4
         } else {
                 ...
@@ -912 +930 @@
 choose ( ... ) {
   case 3:
-        ... ®fallthrough common;®
+        ... @fallthrough common;@
   case 4:
-        ... ®fallthrough common;®
-
-  ®common:® // below fallthrough
+        ... @fallthrough common;@
+
+  @common:@ // below fallthrough
                           // at case-clause level
         ...     // common code for cases 3/4
@@ -932 +950 @@
                 for ( ... ) {
                         // multi-level transfer
-                        ... ®fallthru common;®
+                        ... @fallthru common;@
                 }
                 ...
         }
         ...
-  ®common:® // below fallthrough
+  @common:@ // below fallthrough
                           // at case-clause level
 \end{cfa}
@@ -948 +966 @@
 
 \begin{figure}
-\begin{tabular}{@{}l|l@{}}
-\multicolumn{1}{c|}{loop control} & \multicolumn{1}{c}{output} \\
+\begin{tabular}{@{}l@{\hspace{25pt}}|l@{}}
+\multicolumn{1}{@{}c@{\hspace{25pt}}|}{loop control} & \multicolumn{1}{c@{}}{output} \\
 \hline
-\begin{cfa}[xleftmargin=0pt]
-while ®()® { sout | "empty"; break; }
-do { sout | "empty"; break; } while ®()®;
-for ®()® { sout | "empty"; break; }
-for ( ®0® ) { sout | "A"; } sout | "zero";
-for ( ®1® ) { sout | "A"; }
-for ( ®10® ) { sout | "A"; }
-for ( ®= 10® ) { sout | "A"; }
-for ( ®1 ~= 10 ~ 2® ) { sout | "B"; }
-for ( ®10 -~= 1 ~ 2® ) { sout | "C"; }
-for ( ®0.5 ~ 5.5® ) { sout | "D"; }
-for ( ®5.5 -~ 0.5® ) { sout | "E"; }
-for ( ®i; 10® ) { sout | i; }
-for ( ®i; = 10® ) { sout | i; }
-for ( ®i; 1 ~= 10 ~ 2® ) { sout | i; }
-for ( ®i; 10 -~= 1 ~ 2® ) { sout | i; }
-for ( ®i; 0.5 ~ 5.5® ) { sout | i; }
-for ( ®i; 5.5 -~ 0.5® ) { sout | i; }
-for ( ®ui; 2u ~= 10u ~ 2u® ) { sout | ui; }
-for ( ®ui; 10u -~= 2u ~ 2u® ) { sout | ui; }
+\begin{cfa}
+while @($\,$)@ { sout | "empty"; break; }
+do { sout | "empty"; break; } while @($\,$)@;
+for @($\,$)@ { sout | "empty"; break; }
+for ( @0@ ) { sout | "A"; } sout | "zero";
+for ( @1@ ) { sout | "A"; }
+for ( @10@ ) { sout | "A"; }
+for ( @= 10@ ) { sout | "A"; }
+for ( @1 ~= 10 ~ 2@ ) { sout | "B"; }
+for ( @10 -~= 1 ~ 2@ ) { sout | "C"; }
+for ( @0.5 ~ 5.5@ ) { sout | "D"; }
+for ( @5.5 -~ 0.5@ ) { sout | "E"; }
+for ( @i; 10@ ) { sout | i; }
+for ( @i; = 10@ ) { sout | i; }
+for ( @i; 1 ~= 10 ~ 2@ ) { sout | i; }
+for ( @i; 10 -~= 1 ~ 2@ ) { sout | i; }
+for ( @i; 0.5 ~ 5.5@ ) { sout | i; }
+for ( @i; 5.5 -~ 0.5@ ) { sout | i; }
+for ( @ui; 2u ~= 10u ~ 2u@ ) { sout | ui; }
+for ( @ui; 10u -~= 2u ~ 2u@ ) { sout | ui; }
 enum { N = 10 };
-for ( ®N® ) { sout | "N"; }
-for ( ®i; N® ) { sout | i; }
-for ( ®i; N -~ 0® ) { sout | i; }
+for ( @N@ ) { sout | "N"; }
+for ( @i; N@ ) { sout | i; }
+for ( @i; N -~ 0@ ) { sout | i; }
 const int start = 3, comp = 10, inc = 2;
-for ( ®i; start ~ comp ~ inc + 1® ) { sout | i; }
-for ( i; 1 ~ ®@® ) { if ( i > 10 ) break; sout | i; }
-for ( i; 10 -~ ®@® ) { if ( i < 0 ) break; sout | i; }
-for ( i; 2 ~ ®@® ~ 2 ) { if ( i > 10 ) break; sout | i; }
-for ( i; 2.1 ~ ®@® ~ ®@® ) { if ( i > 10.5 ) break; sout | i; i += 1.7; }
-for ( i; 10 -~ ®@® ~ 2 ) { if ( i < 0 ) break; sout | i; }
-for ( i; 12.1 ~ ®@® ~ ®@® ) { if ( i < 2.5 ) break; sout | i; i -= 1.7; }
-for ( i; 5 ®:® j; -5 ~ @ ) { sout | i | j; }
-for ( i; 5 ®:® j; -5 -~ @ ) { sout | i | j; }
-for ( i; 5 ®:® j; -5 ~ @ ~ 2 ) { sout | i | j; }
-for ( i; 5 ®:® j; -5 -~ @ ~ 2 ) { sout | i | j; }
-for ( i; 5 ®:® j; -5 ~ @ ) { sout | i | j; }
-for ( i; 5 ®:® j; -5 -~ @ ) { sout | i | j; }
-for ( i; 5 ®:® j; -5 ~ @ ~ 2 ) { sout | i | j; }
-for ( i; 5 ®:® j; -5 -~ @ ~ 2 ) { sout | i | j; }
-for ( i; 5 ®:® j; -5 -~ @ ~ 2 ®:® k; 1.5 ~ @ ) { sout | i | j | k; }
-for ( i; 5 ®:® j; -5 -~ @ ~ 2 ®:® k; 1.5 ~ @ ) { sout | i | j | k; }
-for ( i; 5 ®:® k; 1.5 ~ @ ®:® j; -5 -~ @ ~ 2 ) { sout | i | j | k; }
+for ( @i; start ~ comp ~ inc + 1@ ) { sout | i; }
+for ( i; 1 ~ $\R{@}$ ) { if ( i > 10 ) break; sout | i; }
+for ( i; 10 -~ $\R{@}$ ) { if ( i < 0 ) break; sout | i; }
+for ( i; 2 ~ $\R{@}$ ~ 2 ) { if ( i > 10 ) break; sout | i; }
+for ( i; 2.1 ~ $\R{@}$ ~ $\R{@}$ ) { if ( i > 10.5 ) break; sout | i; i += 1.7; }
+for ( i; 10 -~ $\R{@}$ ~ 2 ) { if ( i < 0 ) break; sout | i; }
+for ( i; 12.1 ~ $\R{@}$ ~ $\R{@}$ ) { if ( i < 2.5 ) break; sout | i; i -= 1.7; }
+for ( i; 5 @:@ j; -5 ~ $@$ ) { sout | i | j; }
+for ( i; 5 @:@ j; -5 -~ $@$ ) { sout | i | j; }
+for ( i; 5 @:@ j; -5 ~ $@$ ~ 2 ) { sout | i | j; }
+for ( i; 5 @:@ j; -5 -~ $@$ ~ 2 ) { sout | i | j; }
+for ( i; 5 @:@ j; -5 ~ $@$ ) { sout | i | j; }
+for ( i; 5 @:@ j; -5 -~ $@$ ) { sout | i | j; }
+for ( i; 5 @:@ j; -5 ~ $@$ ~ 2 ) { sout | i | j; }
+for ( i; 5 @:@ j; -5 -~ $@$ ~ 2 ) { sout | i | j; }
+for ( i; 5 @:@ j; -5 -~ $@$ ~ 2 @:@ k; 1.5 ~ $@$ ) { sout | i | j | k; }
+for ( i; 5 @:@ j; -5 -~ $@$ ~ 2 @:@ k; 1.5 ~ $@$ ) { sout | i | j | k; }
+for ( i; 5 @:@ k; 1.5 ~ $@$ @:@ j; -5 -~ $@$ ~ 2 ) { sout | i | j | k; }
 \end{cfa}
 &
@@ -1056 +1074 @@
 \subsection{Loop Control}
 
-The ©for©/©while©/©do-while© loop-control allows empty or simplified ranges (see Figure~\ref{f:LoopControlExamples}).
-\begin{itemize}
+Looping a fixed number of times, possibly with a loop index, occurs frequently.
+\CFA condenses simply looping to facilitate coding speed and safety.
+The ©for©/©while©/©do-while© loop-control is augmented as follows \see{examples in \VRef[Figure]{f:LoopControlExamples}}:
+\begin{itemize}[itemsep=0pt]
+\item
+©0© is the implicit start value;
+\item
+©1© is the implicit increment value.
+\item
+The up-to range uses operator ©+=© for increment;
+\item
+The down-to range uses operator ©-=© for decrement.
 \item
 The loop index is polymorphic in the type of the comparison value N (when the start value is implicit) or the start value M.
+\begin{cfa}
+for ( i; @5@ )                                  $\C[2.5in]{// typeof(5) i; 5 is comparison value}$
+for ( i; @1.5@~5.5~0.5 )                $\C{// typeof(1.5) i; 1.5 is start value}$
+\end{cfa}
 \item
 An empty conditional implies comparison value of ©1© (true).
-\item
-A comparison N is implicit up-to exclusive range [0,N©®)®©.
-\item
-A comparison ©=© N is implicit up-to inclusive range [0,N©®]®©.
-\item
-The up-to range M ©~©\index{~@©~©} N means exclusive range [M,N©®)®©.
-\item
-The up-to range M ©~=©\index{~=@©~=©} N means inclusive range [M,N©®]®©.
-\item
-The down-to range M ©-~©\index{-~@©-~©} N means exclusive range [N,M©®)®©.
-\item
-The down-to range M ©-~=©\index{-~=@©-~=©} N means inclusive range [N,M©®]®©.
-\item
-©0© is the implicit start value;
-\item
-©1© is the implicit increment value.
-\item
-The up-to range uses operator ©+=© for increment;
-\item
-The down-to range uses operator ©-=© for decrement.
+\begin{cfa}
+while ( $\R{/*empty*/}$ )               $\C{// while ( true )}$
+for ( $\R{/*empty*/}$ )                 $\C{// for ( ; true; )}$
+do ... while ( $\R{/*empty*/}$ ) $\C{// do ... while ( true )}$
+\end{cfa}
+\item
+A comparison N is implicit up-to exclusive range [0,N\R{)}.
+\begin{cfa}
+for ( @5@ )                                             $\C{// for ( typeof(5) i; i < 5; i += 1 )}$
+\end{cfa}
+\item
+A comparison ©=© N is implicit up-to inclusive range [0,N\R{]}.
+\begin{cfa}
+for ( @=@5 )                                    $\C{// for ( typeof(5) i; i <= 5; i += 1 )}$
+\end{cfa}
+\item
+The up-to range M ©~©\index{~@©~©} N means exclusive range [M,N\R{)}.
+\begin{cfa}
+for ( 1@~@5 )                                   $\C{// for ( typeof(1) i = 1; i < 5; i += 1 )}$
+\end{cfa}
+\item
+The up-to range M ©~=©\index{~=@©~=©} N means inclusive range [M,N\R{]}.
+\begin{cfa}
+for ( 1@~=@5 )                                  $\C{// for ( typeof(1) i = 1; i <= 5; i += 1 )}$
+\end{cfa}
+\item
+The down-to range M ©-~©\index{-~@©-~©} N means exclusive range [N,M\R{)}.
+\begin{cfa}
+for ( 1@-~@5 )                                  $\C{// for ( typeof(1) i = 5; i > 0; i -= 1 )}$
+\end{cfa}
+\item
+The down-to range M ©-~=©\index{-~=@©-~=©} N means inclusive range [N,M\R{]}.
+\begin{cfa}
+for ( 1@-~=@5 )                                 $\C{// for ( typeof(1) i = 5; i >= 0; i -= 1 )}$
+\end{cfa}
 \item
 ©@© means put nothing in this field.
+\begin{cfa}
+for ( 1~$\R{@}$~2 )                             $\C{// for ( typeof(1) i = 1; /*empty*/; i += 2 )}$
+\end{cfa}
 \item
 ©:© means start another index.
+\begin{cfa}
+for ( i; 5 @:@ j; 2~12~3 )              $\C{// for ( typeof(i) i = 1, j = 2; i < 5 \&\& j < 12; i += 1, j += 3 )}\CRT$
+\end{cfa}
 \end{itemize}
 
@@ -1092 +1145 @@
 \subsection{\texorpdfstring{Labelled \LstKeywordStyle{continue} / \LstKeywordStyle{break} Statement}{Labelled continue / break Statement}}
 
-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.
+C ©continue© and ©break© statements, for altering control flow, are restricted to one level of nesting for a particular control structure.
+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.
 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.
-\VRef[Figure]{f:MultiLevelExit} shows ©continue© and ©break© indicating the specific control structure, and the corresponding C program using only ©goto© and labels.
+\VRef[Figure]{f:MultiLevelExit} shows a comparison between labelled ©continue© and ©break© and the corresponding C equivalent using ©goto© and labels.
 The innermost loop has 8 exit points, which cause continuation or termination of one or more of the 7 \Index{nested control-structure}s.
 
@@ -1104 +1157 @@
 \begin{lrbox}{\myboxA}
 \begin{cfa}[tabsize=3]
-®Compound:® {
-        ®Try:® try {
-                ®For:® for ( ... ) {
-                        ®While:® while ( ... ) {
-                                ®Do:® do {
-                                        ®If:® if ( ... ) {
-                                                ®Switch:® switch ( ... ) {
+@Compound:@ {
+        @Try:@ try {
+                @For:@ for ( ... ) {
+                        @While:@ while ( ... ) {
+                                @Do:@ do {
+                                        @If:@ if ( ... ) {
+                                                @Switch:@ switch ( ... ) {
                                                         case 3:
-                                                                ®break Compound®;
-                                                                ®break Try®;
-                                                                ®break For®;      /* or */  ®continue For®;
-                                                                ®break While®;  /* or */  ®continue While®;
-                                                                ®break Do®;      /* or */  ®continue Do®;
-                                                                ®break If®;
-                                                                ®break Switch®;
+                                                                @break Compound@;
+                                                                @break Try@;
+                                                                @break For@;      /* or */  @continue For@;
+                                                                @break While@;  /* or */  @continue While@;
+                                                                @break Do@;      /* or */  @continue Do@;
+                                                                @break If@;
+                                                                @break Switch@;
                                                         } // switch
                                                 } else {
-                                                        ... ®break If®; ...     // terminate if
+                                                        ... @break If@; ...     // terminate if
                                                 } // if
                                 } while ( ... ); // do
                         } // while
                 } // for
-        } ®finally® { // always executed
+        } @finally@ { // always executed
         } // try
 } // compound
@@ -1136 +1189 @@
 {
 
-                ®ForC:® for ( ... ) {
-                        ®WhileC:® while ( ... ) {
-                                ®DoC:® do {
+                @ForC:@ for ( ... ) {
+                        @WhileC:@ while ( ... ) {
+                                @DoC:@ do {
                                         if ( ... ) {
                                                 switch ( ... ) {
                                                         case 3:
-                                                                ®goto Compound®;
-                                                                ®goto Try®;
-                                                                ®goto ForB®;      /* or */  ®goto ForC®;
-                                                                ®goto WhileB®;  /* or */  ®goto WhileC®;
-                                                                ®goto DoB®;      /* or */  ®goto DoC®;
-                                                                ®goto If®;
-                                                                ®goto Switch®;
-                                                        } ®Switch:® ;
+                                                                @goto Compound@;
+                                                                @goto Try@;
+                                                                @goto ForB@;      /* or */  @goto ForC@;
+                                                                @goto WhileB@;  /* or */  @goto WhileC@;
+                                                                @goto DoB@;      /* or */  @goto DoC@;
+                                                                @goto If@;
+                                                                @goto Switch@;
+                                                        } @Switch:@ ;
                                                 } else {
-                                                        ... ®goto If®; ...      // terminate if
-                                                } ®If:®;
-                                } while ( ... ); ®DoB:® ;
-                        } ®WhileB:® ;
-                } ®ForB:® ;
-
-
-} ®Compound:® ;
+                                                        ... @goto If@; ...      // terminate if
+                                                } @If:@;
+                                } while ( ... ); @DoB:@ ;
+                        } @WhileB:@ ;
+                } @ForB:@ ;
+
+
+} @Compound:@ ;
 \end{cfa}
 \end{lrbox}
 
 \subfloat[\CFA]{\label{f:CFibonacci}\usebox\myboxA}
-\hspace{2pt}
+\hspace{3pt}
 \vrule
-\hspace{2pt}
+\hspace{3pt}
 \subfloat[C]{\label{f:CFAFibonacciGen}\usebox\myboxB}
 \caption{Multi-level Exit}
@@ -1180 +1233 @@
 This restriction prevents missing declarations and/or initializations at the start of a control structure resulting in undefined behaviour.
 \end{itemize}
-The advantage of the labelled ©continue©/©break© is allowing static multi-level exits without having to use the ©goto© statement, and tying control flow to the target control structure rather than an arbitrary point in a program.
+The advantage of the labelled ©continue©/©break© is allowing static multi-level exits without having to use the ©goto© statement, and tying control flow to the target control structure rather than an arbitrary point in a program via a label.
 Furthermore, the location of the label at the \emph{beginning} of the target control structure informs the reader (\Index{eye candy}) that complex control-flow is occurring in the body of the control structure.
 With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
@@ -1187 +1240 @@
 
 
-%\section{\texorpdfstring{\protect\lstinline@with@ Statement}{with Statement}}
-\section{\texorpdfstring{\LstKeywordStyle{with} Statement}{with Statement}}
+%\subsection{\texorpdfstring{\protect\lstinline@with@ Statement}{with Statement}}
+\subsection{\texorpdfstring{\LstKeywordStyle{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}§
-        int i;
-        double d;
+Grouping heterogeneous data into an \newterm{aggregate} (structure/union) is a common programming practice, and aggregates may be nested:
+\begin{cfa}
+struct Person {                                                         $\C{// aggregate}$
+        struct Name { char first[20], last[20]; } name $\C{// nesting}$
+        struct Address { ... } address                  $\C{// nesting}$
+        int sex;
 };
-S s, as[10];
-\end{cfa}
-However, functions manipulating aggregates must repeat the aggregate name to access its containing fields:
-\begin{cfa}
-void f( S s ) {
-        ®s.®c; ®s.®i; ®s.®d; §\C{// access containing fields}§
-}
-\end{cfa}
-which extends to multiple levels of qualification for nested aggregates.
-A similar situation occurs in object-oriented programming, \eg \CC:
+\end{cfa}
+Functions manipulating aggregates must repeat the aggregate name to access its containing fields.
+\begin{cfa}
+Person p
+@p.@name; @p.@address; @p.@sex; $\C{// access containing fields}$
+\end{cfa}
+which extends to multiple levels of qualification for nested aggregates and multiple aggregates.
+\begin{cfa}
+struct Ticket { ... } t;
+@p.name@.first; @p.address@.street;             $\C{// access nested fields}$
+@t.@departure; @t.@cost;                                $\C{// access multiple aggregate}$
+\end{cfa}
+Repeated aggregate qualification is tedious and makes code difficult to read.
+Therefore, reducing aggregate qualification is a useful language design goal.
+
+C allows unnamed nested aggregates that open their scope into the containing aggregate.
+This feature is used to group fields for attributes and/or with ©union© aggregates.
+\begin{cfa}
+struct S {
+        struct { int g,  h; } __attribute__(( aligned(64) ));
+        int tag;
+        union {
+                struct { char c1,  c2; } __attribute__(( aligned(128) ));
+                struct { int i1,  i2; };
+                struct { double d1,  d2; };
+        };
+};
+s.g; s.h; s.tag; s.c1; s.c2; s.i1; s.i2; s.d1; s.d2;
+\end{cfa}
+
+Object-oriented languages reduce qualification for class variables within member functions, \eg \CC:
 \begin{C++}
 struct S {
-        char c; §\C{// fields}§
-        int i;
-        double d;
-        void f() { §\C{// implicit ``this'' aggregate}§
-                ®this->®c; ®this->®i; ®this->®d; §\C{// access containing fields}§
+        char @c@;   int @i@;   double @d@;
+        void f( /* S * this */ ) {                              $\C{// implicit ``this'' parameter}$
+                @c@;   @i@;   @d@;                                      $\C{// this->c; this->i; this->d;}$
         }
 }
 \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.
-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.
-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}§
+In general, qualification is elided for the variables and functions in the lexical scopes visible from a member function.
+However, qualification is necessary for name shadowing and explicit aggregate parameters. 
+\begin{cfa}
+struct T {
+        char @m@;   int @i@;   double @n@;              $\C{// derived class variables}$
+};
+struct S : public T {
+        char @c@;   int @i@;   double @d@;              $\C{// class variables}$
+        void g( double @d@, T & t ) {
+                d;   @t@.m;   @t@.i;   @t@.n;           $\C{// function parameter}$
+                c;   i;   @this->@d;   @S::@d;          $\C{// class S variables}$
+                m;   @T::@i;   n;                                       $\C{// class T variables}$
+        }
+};
+\end{cfa}
+Note the three different forms of qualification syntax in \CC, ©.©, ©->©, ©::©, which is confusing.
+
+Since \CFA in not object-oriented, it has no implicit parameter with its implicit qualification.
+Instead \CFA introduces a general mechanism using the ©with© statement \see{Pascal~\cite[\S~4.F]{Pascal}} to explicitly elide aggregate qualification by opening a scope containing the field identifiers.
+Hence, the qualified fields become variables with the side-effect that it is simpler to write, easier to read, and optimize field references in a block.
+\begin{cfa}
+void f( S & this ) @with ( this )@ {            $\C{// with statement}$
+        @c@;   @i@;   @d@;                                              $\C{// 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:
-\begin{cfa}
-§\emph{with-statement}§:
-        'with' '(' §\emph{expression-list}§ ')' §\emph{compound-statement}§
-\end{cfa}
-and may appear as the body of a function or nested within a function body.
-Each expression in the expression-list provides a type and object.
-The type must be an aggregate type.
+void g( S & s, T & t ) @with ( s, t )@ {        $\C{// multiple aggregate parameters}$
+        c;   @s.@i;   d;                                                $\C{// s.c, s.i, s.d}$
+        m;   @t.@i;   n;                                                $\C{// t.m, t.i, t.n}$
+}
+\end{cfa}
+where qualification is only necessary to disambiguate the shadowed variable ©i©.
+
+In detail, the ©with© statement may appear as the body of a function or nested within a function body.
+The ©with© clause takes a list of expressions, where each expression provides an aggregate type and object.
 (Enumerations are already opened.)
-The object is the implicit qualifier for the open structure-fields.
-
+To open a pointer type, the pointer must be dereferenced to obtain a reference to the aggregate type.
+\begin{cfa}
+S * sp;
+with ( *sp ) { ... }
+\end{cfa}
+The expression object is the implicit qualifier for the open structure-fields.
+\CFA's ability to overload variables \see{\VRef{s:VariableOverload}} and use the left-side of assignment in type resolution means most fields with the same name but different types are automatically disambiguated, eliminating qualification.
 All expressions in the expression list are open in parallel within the compound statement.
 This semantic is different from Pascal, which nests the openings from left to right.
 The difference between parallel and nesting occurs for fields with the same name and type:
 \begin{cfa}
-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©.
-\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}§
+struct Q { int @i@; int k; int @m@; } q, w;
+struct R { int @i@; int j; double @m@; } r, w;
+with ( r, q ) {
+        j + k;                                                                  $\C{// unambiguous, r.j + q.k}$
+        m = 5.0;                                                                $\C{// unambiguous, q.m = 5.0}$
+        m = 1;                                                                  $\C{// unambiguous, r.m = 1}$
+        int a = m;                                                              $\C{// unambiguous, a = r.i }$
+        double b = m;                                                   $\C{// unambiguous, b = q.m}$
+        int c = r.i + q.i;                                              $\C{// disambiguate with qualification}$
+        (double)m;                                                              $\C{// disambiguate with cast}$
+}
+\end{cfa}
+For parallel semantics, both ©r.i© and ©q.i© are visible, so ©i© is ambiguous without qualification;
+for nested semantics, ©q.i© hides ©r.i©, so ©i© implies ©q.i©.
+Pascal nested-semantics is possible by nesting ©with© statements.
+\begin{cfa}
+with ( r ) {
+        i;                                                                              $\C{// unambiguous, r.i}$
+        with ( q ) {
+                i;                                                                      $\C{// unambiguous, q.i}$
+        }
+}
+\end{cfa}
+A cast or qualification can be used to disambiguate variables within a ©with© \emph{statement}.
+A cast can be used to disambiguate among overload variables in a ©with© \emph{expression}:
+\begin{cfa}
+with ( w ) { ... }                                                      $\C{// ambiguous, same name and no context}$
+with ( (Q)w ) { ... }                                           $\C{// unambiguous, cast}$
+\end{cfa}
+Because there is no left-side in the ©with© expression to implicitly disambiguate between the ©w© variables, it is necessary to explicitly disambiguate by casting ©w© to type ©Q© or ©R©.
+
+Finally, 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}
@@ -1291 +1385 @@
 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:
-% \begin{cfa}
-% struct S { int i, j; } sv;
-% with ( sv ) { §\C{// implicit reference}§
-%       S & sr = sv;
-%       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}§
-%               }
-%               i = 2; j = 3; §\C{\color{red}// sr.i, sr.j}§
-%       }
-%       i = 1; j = 2; §\C{\color{red}// sv.i, sv.j}§
-% }
-% \end{cfa}
-
-In \Index{object-oriented} programming, there is an implicit first parameter, often names \textbf{©self©} or \textbf{©this©}, which is elided.
-\begin{C++}
-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}§
-        }
-}
-\end{C++}
-Since \CFA is non-object-oriented, the equivalent object-oriented program looks like:
-\begin{cfa}
-struct S { int i, j; };
-int mem( S & ®this® ) { §\C{// explicit "this" parameter}§
-        ®this.®i = 1; §\C{// "this" is not elided}§
-        ®this.®j = 2;
-}
-\end{cfa}
-but it is cumbersome having to write ``©this.©'' many times in a member.
-
-\CFA provides a ©with© clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elided the "©this.©" by opening a scope containing field identifiers, changing the qualified fields into variables and giving an opportunity for optimizing qualified references.
-\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}§
-}
-\end{cfa}
-which extends to multiple routine parameters:
-\begin{cfa}
-struct T { double m, n; };
-int mem2( S & this1, T & this2 ) ®with( this1, this2 )® {
-        i = 1; j = 2;
-        m = 1.0; n = 2.0;
-}
-\end{cfa}
-
-The statement form is used within a block:
-\begin{cfa}
-int foo() {
-        struct S1 { ... } s1;
-        struct S2 { ... } s2;
-        ®with( s1 )® { §\C{// with statement}§
-                // access fields of s1 without qualification
-                ®with s2® { §\C{// nesting}§
-                        // access fields of s1 and s2 without qualification
-                }
-        }
-        ®with s1, s2® {
-                // access unambiguous fields of s1 and s2 without qualification
-        }
-}
-\end{cfa}
-
-When opening multiple structures, fields with the same name and type are ambiguous and must be fully qualified.
-For fields with the same name but different type, context/cast can be used to disambiguate.
-\begin{cfa}
-struct S { int i; int j; double m; } a, c;
-struct T { int i; int k; int m } b, c;
-with( a, b )
-{
-}
-\end{cfa}
-
-\begin{comment}
-The components in the "with" clause
-
-  with a, b, c { ... }
-
-serve 2 purposes: each component provides a type and object. The type must be a
-structure type. Enumerations are already opened, and I think a union is opened
-to some extent, too. (Or is that just unnamed unions?) The object is the target
-that the naked structure-fields apply to. The components are open in "parallel"
-at the scope of the "with" clause/statement, so opening "a" does not affect
-opening "b", etc. This semantic is different from Pascal, which nests the
-openings.
-
-Having said the above, it seems reasonable to allow a "with" component to be an
-expression. The type is the static expression-type and the object is the result
-of the expression. Again, the type must be an aggregate. Expressions require
-parenthesis around the components.
-
-  with( a, b, c ) { ... }
-
-Does this now make sense?
-
-Having written more CFA code, it is becoming clear to me that I *really* want
-the "with" to be implemented because I hate having to type all those object
-names for fields. It's a great way to drive people away from the language.
-\end{comment}
+void ?{}( S & s, int @i@ ) with ( s ) @with( $\emph{\R{params}}$ )@ { // syntax not allowed, illustration only
+        s.i = @i@; j = 3; m = 5.5;
+}
+\end{cfa}
+This implicit semantic matches with programmer expectation.
+
 
 
@@ -1414 +1400 @@
 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{// termination handler}§
+} catch( E e ; $boolean-predicate$ ) {          $\C{// termination handler}$
         // recover and continue
-} catchResume( E e ; §boolean-predicate§ ) { §\C{// resumption handler}§
+} catchResume( E e ; $boolean-predicate$ ) { $\C{// resumption handler}$
         // repair and return
 } finally {
@@ -1430 +1416 @@
 \end{cfa}
 The kind of raise and handler match: ©throw© with ©catch© and ©throwResume© with ©catchResume©.
-Then the exception type must match along with any additonal predicate must be true.
+Then the exception type must match along with any additional predicate must be true.
 The ©catch© and ©catchResume© handlers may appear in any oder.
 However, the ©finally© clause must appear at the end of the ©try© statement.
@@ -1483 +1469 @@
 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}).
@@ -1499 +1485 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
-\begin{cfa}
-ß[5] *ß ®int® x1;
-ß* [5]ß ®int® x2;
-ß[* [5] int]ß f®( int p )®;
+\begin{cfa}[moredelim={**[is][\color{blue}]{\#}{\#}}]
+#[5] *# @int@ x1;
+#* [5]# @int@ x2;
+#[* [5] int]# f@( int p )@;
 \end{cfa}
 &
-\begin{cfa}
-®int® ß*ß x1 ß[5]ß;
-®int® ß(*ßx2ß)[5]ß;
-ßint (*ßf®( int p )®ß)[5]ß;
+\begin{cfa}[moredelim={**[is][\color{blue}]{\#}{\#}}]
+@int@ #*# x1 #[5]#;
+@int@ #(*#x2#)[5]#;
+#int (*#f@( int p )@#)[5]#;
 \end{cfa}
 \end{tabular}
@@ -1520 +1506 @@
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
-®*® int x, y;
+@*@ int x, y;
 \end{cfa}
 &
 \begin{cfa}
-int ®*®x, ®*®y;
+int @*@x, @*@y;
 \end{cfa}
 \end{tabular}
@@ -1533 +1519 @@
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
-®*® int x;
+@*@ int x;
 int y;
 \end{cfa}
 &
 \begin{cfa}
-int ®*®x, y;
+int @*@x, y;
 
 \end{cfa}
@@ -1647 +1633 @@
 
 \section{Pointer / Reference}
+\label{s:PointerReference}
 
 C provides a \newterm{pointer type};
@@ -1673 +1660 @@
 &
 \begin{cfa}
-int * ®const® x = (int *)100
+int * @const@ x = (int *)100
 *x = 3;                 // implicit dereference
-int * ®const® y = (int *)104;
+int * @const@ y = (int *)104;
 *y = *x;                        // implicit dereference
 \end{cfa}
@@ -1713 +1700 @@
 \begin{tabular}{@{}l@{\hspace{2em}}l@{}}
 \begin{cfa}
-int x, y, ®*® p1, ®*® p2, ®**® p3;
-p1 = ®&®x;     // p1 points to x
+int x, y, @*@ p1, @*@ p2, @**@ p3;
+p1 = @&@x;     // p1 points to x
 p2 = p1;     // p2 points to x
-p1 = ®&®y;     // p1 points to y
+p1 = @&@y;     // p1 points to y
 p3 = &p2;  // p3 points to p2
 \end{cfa}
@@ -1728 +1715 @@
 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.
@@ -1736 +1723 @@
 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©).
@@ -1758 +1745 @@
 To support this common case, a reference type is introduced in \CFA, denoted by ©&©, which is the opposite dereference semantics to a pointer type, making the value at the pointed-to location the implicit semantics for dereferencing (similar but not the same as \CC \Index{reference type}s).
 \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}§
-r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§
+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}$
+r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); $\C{// implicit dereferencing}$
 \end{cfa}
 Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
@@ -1769 +1756 @@
 One way to conceptualize a reference is via a rewrite rule, where the compiler inserts a dereference operator before the reference variable for each reference qualifier in a declaration, so the previous example becomes:
 \begin{cfa}
-®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
+@*@r2 = ((@*@r1 + @*@r2) @*@ (@**@r3 - @*@r1)) / (@**@r3 - 15);
 \end{cfa}
 When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.
@@ -1778 +1765 @@
 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.
@@ -1790 +1777 @@
 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.
@@ -1803 +1790 @@
 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:
@@ -1822 +1809 @@
 cr = 5;
 free( &cr );
-cr = 7; §\C{// unsound pointer dereference}§
+cr = 7; $\C{// unsound pointer dereference}$
 \end{cfa}
 
 The position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
 The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
-\CFA-style declarations (see \VRef{s:AlternativeDeclarations}) attempt to address this issue:
+\CFA-style declarations \see{\VRef{s:AlternativeDeclarations}} attempt to address this issue:
 \begin{cquote}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
-®const® * ®const® * const int ccp;
-®const® & ®const® & const int ccr;
+@const@ * @const@ * const int ccp;
+@const@ & @const@ & const int ccr;
 \end{cfa}
 &
 \begin{cfa}
-const int * ®const® * ®const® ccp;
+const int * @const@ * @const@ ccp;
 
 \end{cfa}
@@ -1846 +1833 @@
 Finally, like pointers, references are usable and composable with other type operators and generators.
 \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}§
+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}$
 \end{cfa}
 
 In contrast to \CFA reference types, \Index*[C++]{\CC{}}'s reference types are all ©const© references, preventing changes to the reference address, so only value assignment is possible, which eliminates half of the \Index{address duality}.
 Also, \CC does not allow \Index{array}s\index{array!reference} of reference\footnote{
-The reason for disallowing arrays of reference is unknown, but possibly comes from references being ethereal (like a textual macro), and hence, replaceable by the referant object.}
+The reason for disallowing arrays of reference is unknown, but possibly comes from references being ethereal (like a textual macro), and hence, replaceable by the referent object.}
 \Index*{Java}'s reference types to objects (all Java objects are on the heap) are like C pointers, which always manipulate the address, and there is no (bit-wise) object assignment, so objects are explicitly cloned by shallow or deep copying, which eliminates half of the address duality.
 
@@ -1868 +1855 @@
 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).
@@ -1879 +1866 @@
 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©.
@@ -1893 +1880 @@
 When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
 \begin{cfa}
-void f( ®const® int & cr );
-void g( ®const® int * cp );
-f( 3 );                   g( ®&®3 );
-f( x + y );             g( ®&®(x + y) );
+void f( @const@ int & cr );
+void g( @const@ int * cp );
+f( 3 );                   g( @&@3 );
+f( x + y );             g( @&@(x + y) );
 \end{cfa}
 Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
@@ -1907 +1894 @@
 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{
@@ -1919 +1906 @@
 \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{
@@ -1946 +1933 @@
 \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\cdots$ ©&©$_r$, where $r \ge 1$ references (©&© symbols), than ©&R© has type ©T ©\R{©*©}©&©\R{$_2$}$\cdots$ ©&©\R{$_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 ©\R{©*©}©&©\R{$_1$}$\cdots$ ©&©\R{$_l$}, \ie ©T© pointer with $l$ references (©&© symbols).
 \end{itemize}
 The following example shows the first rule applied to different \Index{rvalue} contexts:
@@ -1955 +1942 @@
 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; $\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)}$
 \end{cfa}
 The following example shows the second rule applied to different \Index{lvalue} contexts:
@@ -1965 +1952 @@
 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; $\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$
 \end{cfa}
 
@@ -1981 +1968 @@
 \begin{cfa}
 int x;
-x + 1; §\C[2.0in]{// lvalue variable (int) converts to rvalue for expression}§
+x + 1; $\C[2.0in]{// lvalue variable (int) converts to rvalue for expression}$
 \end{cfa}
 An rvalue has no type qualifiers (©cv©), so the lvalue qualifiers are dropped.
@@ -1991 +1978 @@
 \begin{cfa}
 int x, &r = x, f( int p );
-x = ®r® + f( ®r® ); §\C{// lvalue reference converts to rvalue}§
+x = @r@ + f( @r@ ); $\C{// lvalue reference converts to rvalue}$
 \end{cfa}
 An rvalue has no type qualifiers (©cv©), so the reference qualifiers are dropped.
@@ -1998 +1985 @@
 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 ); $\C{// lvalue variable (int) convert to reference (int \&)}$
+f( @x@ ); $\C{// 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.
@@ -2009 +1996 @@
 \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@ );   $\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$
 \end{cfa}
 In both case, modifications to the temporary are inaccessible (\Index{warning}).
@@ -2182 +2169 @@
 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
 \begin{cfa}
-®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
-        §\emph{routine body}§
+@[ int o1, int o2, char o3 ]@ f( int i1, char i2, char i3 ) {
+        $\emph{routine body}$
 }
 \end{cfa}
@@ -2194 +2181 @@
 Declaration qualifiers can only appear at the start of a routine definition, \eg:
 \begin{cfa}
-®extern® [ int x ] g( int y ) {§\,§}
+@extern@ [ int x ] g( int y ) {$\,$}
 \end{cfa}
 Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified;
 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}
 
@@ -2218 +2205 @@
 \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.
@@ -2226 +2213 @@
 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.
@@ -2252 +2239 @@
 \begin{minipage}{\linewidth}
 \begin{cfa}
-®[ int x, int y ]® f() {
+@[ int x, int y ]@ f() {
         int z;
         ... x = 0; ... y = z; ...
-        ®return;® §\C{// implicitly return x, y}§
+        @return;@ $\C{// implicitly return x, y}$
 }
 \end{cfa}
@@ -2265 +2252 @@
 [ 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.
@@ -2274 +2261 @@
 [ 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 ) ) );
@@ -2292 +2279 @@
 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).
-Like C, it is possible to declare multiple routine-prototypes in a single declaration, where the return type is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:AlternativeDeclarations}), \eg:
+Like C, it is possible to declare multiple routine-prototypes in a single declaration, where the return type is distributed across \emph{all} routine names in the declaration list \see{\VRef{s:AlternativeDeclarations}}, \eg:
 \begin{cfa}
 C :             const double bar1(), bar2( int ), bar3( double );
-§\CFA§: [const double] foo(), foo( int ), foo( double ) { return 3.0; }
+$\CFA$: [const double] foo(), foo( int ), foo( double ) { return 3.0; }
 \end{cfa}
 \CFA allows the last routine in the list to define its body.
@@ -2316 +2303 @@
 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[2.25in]{// 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}\CRT$
 \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}
 
@@ -2347 +2334 @@
 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.
@@ -2364 +2351 @@
 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.
@@ -2380 +2367 @@
 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.
@@ -2400 +2387 @@
 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.
@@ -2435 +2422 @@
 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.
@@ -2452 +2439 @@
 \begin{cfa}
 p( int x, int y, int z, ... );
-p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
-p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
+p( 1, 4, 5, 6, z : 3, y : 2 ); $\C{// assume p( /* positional */, ... , /* named */ );}$
+p( 1, z : 3, y : 2, 4, 5, 6 ); $\C{// assume p( /* positional */, /* named */, ... );}$
 \end{cfa}
 In the first call, it is necessary for the programmer to conceptually rewrite the call, changing named arguments into positional, before knowing where the ellipse arguments begin.
@@ -2462 +2449 @@
 \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;
@@ -2469 +2456 @@
 In the second call, the default value for y is implicitly inserted after argument 1 and the named arguments separate the positional and ellipse arguments, making it trivial to read the call.
 For these reasons, \CFA requires named arguments before ellipse arguments.
-Finally, while ellipse arguments are needed for a small set of existing C routines, like printf, the extended \CFA type system largely eliminates the need for ellipse arguments (see Section 24), making much of this discussion moot.
-
-Default arguments and overloading (see Section 24) are complementary.
+Finally, while ellipse arguments are needed for a small set of existing C routines, like ©printf©, the extended \CFA type system largely eliminates the need for ellipse arguments \see{\VRef{s:Overloading}}, making much of this discussion moot.
+
+Default arguments and overloading \see{\VRef{s:Overloading}} are complementary.
 While in theory default arguments can be simulated with overloading, as in:
 \begin{cquote}
@@ -2493 +2480 @@
 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}
 
@@ -2506 +2493 @@
 \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}
@@ -2519 +2506 @@
 \begin{cfa}
 struct {
-        int , , ; §\C{// 3 unnamed fields}§
+        int , , ; $\C{// 3 unnamed fields}$
 }
 \end{cfa}
@@ -2531 +2518 @@
 \subsection{Type Nesting}
 
-\CFA allows \Index{type nesting}, and type qualification of the nested types (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
+\CFA allows \Index{type nesting}, and type qualification of the nested types \see{\VRef[Figure]{f:TypeNestingQualification}}, where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
 \begin{figure}
 \centering
@@ -2587 +2574 @@
 
 int fred() {
-        s.t.c = ®S.®R;  // type qualification
-        struct ®S.®T t = { ®S.®R, 1, 2 };
-        enum ®S.®C c;
-        union ®S.T.®U u;
+        s.t.c = @S.@R;  // type qualification
+        struct @S.@T t = { @S.@R, 1, 2 };
+        enum @S.@C c;
+        union @S.T.@U u;
 }
 \end{cfa}
@@ -2613 +2600 @@
 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}§
+        @int ?<?( int x, int y ) { return x > y; }@ $\C{// nested routine}$
+        qsort( ia, size ); $\C{// sort descending order by local redefinition}$
 }
 \end{cfa}
@@ -2625 +2612 @@
 The following program in undefined in \CFA (and Indexc{gcc})
 \begin{cfa}
-[* [int]( int )] foo() { §\C{// int (* foo())( int )}§
-        int ®i® = 7;
+[* [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@;
         }
-        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 )}§
+        * [int]( int ) fp = foo(); $\C{// int (* fp)( int )}$
         sout | fp( 3 );
 }
@@ -2647 +2634 @@
 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}.
@@ -2656 +2643 @@
 
 In C and most programming languages, functions return at most one value;
-however, many operations have multiple outcomes, some exceptional (see~\VRef{s:ExceptionHandling}).
+however, many operations have multiple outcomes, some exceptional \see{\VRef{s:ExceptionHandling}}.
 To emulate functions with multiple return values, \emph{\Index{aggregation}} and/or \emph{\Index{aliasing}} is used.
 
@@ -2662 +2649 @@
 For example, consider C's \Indexc{div} function, which returns the quotient and remainder for a division of an integer value.
 \begin{cfa}
-typedef struct { int quot, rem; } div_t;        §\C[7cm]{// from include stdlib.h}§
+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.
@@ -2675 +2662 @@
 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.
@@ -2704 +2691 @@
 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.
@@ -2716 +2703 @@
 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.
@@ -2730 +2717 @@
 \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.
@@ -2760 +2747 @@
 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}.
@@ -2767 +2754 @@
 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}
 
@@ -2790 +2777 @@
 [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.
@@ -2801 +2788 @@
 
 \subsection{Flattening and Structuring}
+\label{s:FlatteningStructuring}
 
 As evident in previous examples, tuples in \CFA do not have a rigid structure.
@@ -2861 +2849 @@
 double y;
 [int, double] z;
-[y, x] = 3.14; §\C{// mass assignment}§
-[x, y] = z;                                                         §\C{// multiple assignment}§
-z = 10;                                                         §\C{// mass assignment}§
-z = [x, y]; §\C{// multiple 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}$
 \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.
@@ -2872 +2860 @@
 \begin{cfa}
 [ int, int ] x, y, z;
-[ x, y ] = z;                                              §\C{// multiple assignment, invalid 4 != 2}§
+[ x, y ] = z;                                              $\C{// multiple assignment, invalid 4 != 2}$
 \end{cfa}
 Multiple assignment assigns $R_i$ to $L_i$ for each $i$.
@@ -2908 +2896 @@
         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 ); $\C{// 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.
@@ -2921 +2909 @@
 \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 *); $\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}$
 \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)©.
@@ -2969 +2957 @@
 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;
@@ -2980 +2968 @@
 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}
@@ -2998 +2986 @@
 \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}
 
@@ -3011 +2999 @@
 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(); $\C{// (1)}$
+double f(); $\C{// (2)}$
+
+f(); $\C{// ambiguous - (1),(2) both equally viable}$
+(int)f(); $\C{// 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.
@@ -3023 +3011 @@
 void g();
 
-(void)f(); §\C{// valid, ignore results}§
-(int)g(); §\C{// invalid, void cannot be converted to int}§
+(void)f(); $\C{// valid, ignore results}$
+(int)g(); $\C{// 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(); $\C{// invalid, int cannot be converted to A}$
 \end{cfa}
 In C, line 4 is a valid cast, which calls ©f© and discards its result.
@@ -3043 +3031 @@
         [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(); $\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}$
 \end{cfa}
 
@@ -3107 +3095 @@
 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); $\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}$
 \end{cfa}
 
@@ -3146 +3134 @@
 The general syntax of a lexical list is:
 \begin{cfa}
-[ §\emph{exprlist}§ ]
+[ $\emph{exprlist}$ ]
 \end{cfa}
 where ©$\emph{exprlist}$© is a list of one or more expressions separated by commas.
@@ -3158 +3146 @@
 Tuples are permitted to contain sub-tuples (\ie nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.
 Note, a tuple is not a record (structure);
-a record denotes a single value with substructure, whereas a tuple is multiple values with no substructure (see flattening coercion in Section 12.1).
+a record denotes a single value with substructure, whereas a tuple is multiple values with no substructure \see{flattening coercion in \VRef{s:FlatteningStructuring}}.
 In essence, tuples are largely a compile time phenomenon, having little or no runtime presence.
 
@@ -3166 +3154 @@
 The general syntax of a tuple type is:
 \begin{cfa}
-[ §\emph{typelist}§ ]
+[ $\emph{typelist}$ ]
 \end{cfa}
 where ©$\emph{typelist}$© is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
@@ -3173 +3161 @@
 [ 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}
@@ -3180 +3168 @@
 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}
@@ -3198 +3186 @@
 [ 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); $\C{// three input parameters of type int}$
+[ void ] g ([ int, int, int ]); $\C{3 element tuple as input}$
 f( [ 1, 2, 3 ] );
 f( w1, 3 );
@@ -3279 +3267 @@
 [ 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;
@@ -3285 +3273 @@
 This tuple is then flattened, yielding ©[ 1, 2, 3, 4, 5 ]©, which is structured into ©[ 1, [ 2, 3, 4, 5 ] ]© to match the tuple type of the left-hand side.
 The tuple ©[ 2, 3, 4, 5 ]© is then closed to create a tuple value.
-Finally, ©x© is assigned ©1© and ©w© is assigned the tuple value using multiple assignment (see Section 14).
+Finally, ©x© is assigned ©1© and ©w© is assigned the tuple value using \Index{multiple assignment} \see{\VRef{s:TupleAssignment}}.
 \begin{rationale}
 A possible additional language extension is to use the structuring coercion for tuples to initialize a complex record with a tuple.
@@ -3296 +3284 @@
 Mass assignment has the following form:
 \begin{cfa}
-[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;
+[ $\emph{lvalue}$, ... , $\emph{lvalue}$ ] = $\emph{expr}$;
 \end{cfa}
 \index{lvalue}
@@ -3336 +3324 @@
 Multiple assignment has the following form:
 \begin{cfa}
-[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ];
+[ $\emph{lvalue}$, ... , $\emph{lvalue}$ ] = [ $\emph{expr}$, ... , $\emph{expr}$ ];
 \end{cfa}
 \index{lvalue}
@@ -3367 +3355 @@
 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 right-hand side of multiple assignment}$
 \end{cfa}
 
@@ -3377 +3365 @@
 Cascade assignment has the following form:
 \begin{cfa}
-§\emph{tuple}§ = §\emph{tuple}§ = ... = §\emph{tuple}§;
+$\emph{tuple}$ = $\emph{tuple}$ = ... = $\emph{tuple}$;
 \end{cfa}
 and it has the same parallel semantics as for mass and multiple assignment.
@@ -3424 +3412 @@
 \begin{cfa}
 int x = 1, y = 2, z = 3;
-sout | x ®|® y ®|® z;
+sout | x @|@ y @|@ z;
 \end{cfa}
 &
 \begin{cfa}
 
-cout << x ®<< " "® << y ®<< " "® << z << endl;
+cout << x @<< " "@ << y @<< " "@ << z << endl;
 \end{cfa}
 &
@@ -3438 +3426 @@
 \\
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-1® ®2® ®3
+1@ @2@ @3
 \end{cfa}
 &
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-1® ®2® ®3
+1@ @2@ @3
 \end{cfa}
 &
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-1® ®2® ®3
+1@ @2@ @3
 \end{cfa}
 \end{tabular}
@@ -3454 +3442 @@
 \begin{cfa}
 [int, [ int, int ] ] t1 = [ 1, [ 2, 3 ] ], t2 = [ 4, [ 5, 6 ] ];
-sout | t1 | t2; §\C{// print tuples}§
+sout | t1 | t2; $\C{// print tuples}$
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt]
-1®, ®2®, ®3 4®, ®5®, ®6
+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.
@@ -3466 +3454 @@
 &
 \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@)@;
 \end{cfa}
 \\
@@ -3472 +3460 @@
 &
 \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}
 \\
@@ -3507 +3495 @@
 \\
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®1® ®2.5® ®A®
+@1@ @2.5@ @A@
 
 
@@ -3513 +3501 @@
 &
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®1® ®2.5® ®A®
+@1@ @2.5@ @A@
 
 
@@ -3519 +3507 @@
 &
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®1®
-®2.5®
-®A®
+@1@
+@2.5@
+@A@
 \end{cfa}
 \end{tabular}
@@ -3557 +3545 @@
 
 \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.
-\begin{cfa}[belowskip=0pt]
+A separator does not appear before a C string starting with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \LstStringStyle{,.;!?)]\}\%\textcent\guillemotright}, where \LstStringStyle{\guillemotright} a closing citation mark.
+\begin{cfa}
 sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
-                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x";
-\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.
+           | 7 | "$\LstStringStyle{\textcent}$ x" | 8 | "$\LstStringStyle{\guillemotright}$ x" | 9 | ") x" | 10 | "] x" | 11 | "} x";
+\end{cfa}
+\begin{cfa}[showspaces=true]
+1@,@ x 2@.@ x 3@;@ x 4@!@ x 5@?@ x 6@%@ x 7$\R{\LstStringStyle{\textcent}}$ x 8$\R{\LstStringStyle{\guillemotright}}$ 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: \LstStringStyle{([\{=\$\textsterling\textyen\textexclamdown\textquestiondown\guillemotleft}, where \LstStringStyle{\textexclamdown\textquestiondown} are inverted opening exclamation and question marks, and \LstStringStyle{\guillemotleft} 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;
+\begin{cfa}
+sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x $\LstStringStyle{\textsterling}$" | 6 | "x $\LstStringStyle{\textyen}$"
+           | 7 | "x $\LstStringStyle{\textexclamdown}$" | 8 | "x $\LstStringStyle{\textquestiondown}$" | 9 | "x $\LstStringStyle{\guillemotleft}$" | 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
+\begin{cfa}[showspaces=true]
+x @(@1 x @[@2 x @{@3 x @=@4 x $\LstStringStyle{\textdollar}$5 x $\R{\LstStringStyle{\textsterling}}$6 x $\R{\LstStringStyle{\textyen}}$7 x $\R{\LstStringStyle{\textexclamdown}}$8 x $\R{\LstStringStyle{\textquestiondown}}$9 x $\R{\LstStringStyle{\guillemotleft}}$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@
-\begin{cfa}[belowskip=0pt]
+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}
+\begin{cfa}
 sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx";
 \end{cfa}
-\begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
-x®`®1®`®x§\color{red}\texttt{'}§2§\color{red}\texttt{'}§x§\color{red}\texttt{"}§3§\color{red}\texttt{"}§x®:®4®:®x® ®5® ®x®      ®6®     ®x
+\begin{cfa}[showspaces=true,showtabs=true]
+x@`@1@`@x$\R{\texttt{'}}$2$\R{\texttt{'}}$x$\R{\texttt{"}}$3$\R{\texttt{"}}$x@:@4@:@x@ @5@ @x@  @6@     @x
 \end{cfa}
 
 \item
 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;
-\end{cfa}
-\begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
-x (® ®1® ®) x 2® ®, x 3® ®:x:® ®4
+\begin{cfa}
+sout | "x ($\R{\texttt{\textvisiblespace}}$" | 1 | "$\R{\texttt{\textvisiblespace}}$) x" | 2 | "$\R{\texttt{\textvisiblespace}}$, x" | 3 | "$\R{\texttt{\textvisiblespace}}$:x:$\R{\texttt{\textvisiblespace}}$" | 4;
+\end{cfa}
+\begin{cfa}[showspaces=true,showtabs=true]
+x (@ @1@ @) x 2@ @, x 3@ @:x:@ @4
 \end{cfa}
 \end{enumerate}
@@ -3608 +3595 @@
 \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® | "\"";
+\begin{cfa}[escapechar=off,belowskip=0pt]
+sepSet( sout, ", $" ); $\C{// set separator from " " to ", \$"}$
+sout | 1 | 2 | 3 | " \"" | @sep@ | "\"";
 \end{cfa}
 %$
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
-1®, $®2®, $®3 ®", $"®
+1@, $@2@, $@3 @", $"@
 \end{cfa}
 %$
 \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 )@ | "\"";
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt]
-1® ®2® ®3 ®" "®
+1@ @2@ @3 @" "@
 \end{cfa}
 ©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}§
+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;
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-1®_®2®_®3
+1@_@2@_@3
 \end{cfa}
 \begin{cfa}[belowskip=0pt]
-sepSet( sout, store ); §\C{// change separator back to original}§
+sepSet( sout, store ); $\C{// change separator back to original}$
 sout | 1 | 2 | 3;
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt]
-1® ®2® ®3
+1@ @2@ @3
 \end{cfa}
 
@@ -3646 +3633 @@
 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@ | "\"";
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt]
-1 2 3 4 5 6 ®" "®
+1 2 3 4 5 6 @" "@
 \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 )@ | "\"";
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt]
-1, 2, 3 4, 5, 6 ®", "®
+1, 2, 3 4, 5, 6 @", "@
 \end{cfa}
 As for ©sepGet©, ©sepGetTuple© can be use to store a tuple separator and then restore it.
@@ -3664 +3651 @@
 \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} toggle printing the separator.
 \begin{cfa}[belowskip=0pt]
-sout | sepDisable | 1 | 2 | 3; §\C{// turn off implicit separator}§
+sout | sepDisable | 1 | 2 | 3; $\C{// turn off implicit separator}$
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3670 +3657 @@
 \end{cfa}
 \begin{cfa}[belowskip=0pt]
-sout | sepEnable | 1 | 2 | 3; §\C{// turn on implicit separator}§
+sout | sepEnable | 1 | 2 | 3; $\C{// turn on implicit separator}$
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3679 +3666 @@
 \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.
 \begin{cfa}[belowskip=0pt]
-sout | 1 | sepOff | 2 | 3; §\C{// turn off implicit separator for the next item}§
+sout | 1 | sepOff | 2 | 3; $\C{// turn off implicit separator for the next item}$
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3685 +3672 @@
 \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; $\C{// turn on implicit separator for the next item}$
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3692 +3679 @@
 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; $\C{// turn off implicit separator for the next item}$
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3700 +3687 @@
 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; $\C{// sepOn does nothing at start/end of line}$
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -3706 +3693 @@
 \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 ; $\C{// use sep to print separator at start/end of line}$
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-® ®1 2 3® ®
+@ @1 2 3@ @
 \end{cfa}
 \end{enumerate}
@@ -3721 +3708 @@
 \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.
+\Indexc{nl}\index{manipulator!nl@©nl©} scans characters until the next newline character, \ie ignore the remaining characters in the line.
 \item
 \Indexc{nlOn}\index{manipulator!nlOn@©nlOn©} reads the newline character, when reading single characters.
@@ -3729 +3716 @@
 For example, in:
 \begin{cfa}
-sin | i | ®nl® | j;
-1 ®2®
+sin | i | @nl@ | j;
+1 @2@
 3
 \end{cfa}
@@ -3740 +3727 @@
 \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}§
+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
@@ -3771 +3758 @@
 0b0 0b11011 0b11011 0b11011 0b11011
 sout | bin( -27HH ) | bin( -27H ) | bin( -27 ) | bin( -27L );
-0b11100101 0b1111111111100101 0b11111111111111111111111111100101 0b®(58 1s)®100101
+0b11100101 0b1111111111100101 0b11111111111111111111111111100101 0b@(58 1s)@100101
 \end{cfa}
 
@@ -3810 +3797 @@
 \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
+0@B@11011 0@X@1@B@ 2.75@E@-09 0@X@1.@B@8@P@+4
 \end{cfa}
 
@@ -3826 +3813 @@
 \begin{cfa}[belowskip=0pt]
 sout | 0. | nodp( 0. ) | 27.0 | nodp( 27.0 ) | nodp( 27.5 );
-0.0 ®0® 27.0 ®27® 27.5
+0.0 @0@ 27.0 @27@ 27.5
 \end{cfa}
 
@@ -3833 +3820 @@
 \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
+@+@27 -27 @+@27.0 -27.0 @+@27.5 -27.5
 \end{cfa}
 
@@ -3846 +3833 @@
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®  ®34 ® ®34 34
-®  ®4.000000 ® ®4.000000 4.000000
-®  ®ab ® ®ab ab
+@  @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©.
@@ -3857 +3844 @@
 \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®
+3456@7@ 345@67@ 34@567@
+3456@.@ 345@6.@ 34@56.@
+abcd@e@ abc@de@ ab@cde@
 \end{cfa}
 
@@ -3868 +3855 @@
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
- ®0®34     ®00®34 ®00000000®34
+ @0@34     @00@34 @00000000@34
 \end{cfa}
 If the value is larger, it is printed without truncation, ignoring the ©precision©.
@@ -3883 +3870 @@
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®    ® ®00000000®34
+@    @ @00000000@34
 \end{cfa}
 For floating-point types, ©precision© is the minimum number of digits after the decimal point.
@@ -3890 +3877 @@
 \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.
+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 truncated if it exceeds the maximum.
 \begin{cfa}[belowskip=0pt]
 sout | wd( 6,8, "abcd" ) | wd( 6,8, "abcdefghijk" ) | wd( 6,3, "abcd" );
@@ -3908 +3895 @@
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-234.567 234.5®7®  234.®6®    23®5®
+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.
@@ -3915 +3902 @@
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-234567. 2.3457®e+05® 2.346®e+05® 2.35®e+05®
+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.
@@ -3931 +3918 @@
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-27®  ® 27.000000  27.500000  027  27.500®    ®
+27@  @ 27.000000  27.500000  027  27.500@    @
 \end{cfa}
 
@@ -3938 +3925 @@
 \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
+@00@27  @0@27 @00@27.500
 \end{cfa}
 \end{enumerate}
@@ -4034 +4021 @@
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®abc   ®
-®abc  ®
-®xx®
+@abc   @
+@abc  @
+@xx@
 \end{cfa}
 
@@ -4047 +4034 @@
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®abcd1233.456E+2®
+@abcd1233.456E+2@
 \end{cfa}
 Note, input ©wdi© cannot be overloaded with output ©wd© because both have the same parameters but return different types.
@@ -4060 +4047 @@
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®  -75.35e-4® 25
+@  -75.35e-4@ 25
 \end{cfa}
 
@@ -4072 +4059 @@
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®bca®xyz
+@bca@xyz
 \end{cfa}
 
@@ -4084 +4071 @@
 \end{cfa}
 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
-®xyz®bca
+@xyz@bca
 \end{cfa}
 \end{enumerate}
@@ -4101 +4088 @@
 
 A type definition is different from a typedef in C because a typedef just creates an alias for a type,  while Do.s type definition creates a distinct type.
-This means that users can define distinct function overloads for the new type (see Overloading for more information).
+This means that users can define distinct function overloads for the new type \see{\VRef{s:Overloading} for more information}.
 For example:
 
@@ -4207 +4194 @@
 \CFA supports C initialization of structures, but it also adds constructors for more advanced initialization.
 Additionally, \CFA adds destructors that are called when a variable is deallocated (variable goes out of scope or object is deleted).
-These functions take a reference to the structure as a parameter (see References for more information).
+These functions take a reference to the structure as a parameter \see{\VRef{s:PointerReference} for more information}.
 
 \begin{figure}
@@ -4258 +4245 @@
 
 \section{Overloading}
+\label{s:Overloading}
 
 Overloading refers to the capability of a programmer to define and use multiple objects in a program with the same name.
@@ -4290 +4278 @@
 
 
-\subsection{Overloaded Constant}
+\subsection{Constant}
 
 The constants 0 and 1 have special meaning.
@@ -4329 +4317 @@
 
 
-\subsection{Variable Overloading}
+\subsection{Variable}
+\label{s:VariableOverload}
 
 The overload rules of \CFA allow a programmer to define multiple variables with the same name, but different types.
@@ -4372 +4361 @@
 
 
-\subsection{Operator Overloading}
+\subsection{Operator}
 
 \CFA also allows operators to be overloaded, to simplify the use of user-defined types.
@@ -4468 +4457 @@
 For example, given
 \begin{cfa}
-auto j = ®...®
+auto j = @...@
 \end{cfa}
 and the need to write a routine to compute using ©j©
 \begin{cfa}
-void rtn( ®...® parm );
+void rtn( @...@ parm );
 rtn( j );
 \end{cfa}
@@ -4713 +4702 @@
 
 coroutine Fibonacci {
-        int fn; §\C{// used for communication}§
+        int fn; $\C{// used for communication}$
 };
 void ?{}( Fibonacci * this ) {
@@ -4719 +4708 @@
 }
 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;
 }
@@ -4964 +4953 @@
 When building a \CFA module which needs to be callable from C code, users can use the tools to generate a header file suitable for including in these C files with all of the needed declarations.
 
-In order to interoperate with existing C code, \CFA files can still include header files, the contents of which will be enclosed in a C linkage section to indicate C calling conventions (see Interoperability for more information).
+In order to interoperate with existing C code, \CFA files can still include header files, the contents of which will be enclosed in a C linkage section to indicate C calling conventions \see{\VRef{s:Interoperability} for more information}.
 
 
@@ -5630 +5619 @@
 \end{cfa}
 &
-\begin{lstlisting}[language=C++]
+\begin{C++}
 class Line {
         float lnth;
@@ -5657 +5646 @@
 Line line1;
 Line line2( 3.4 );
-\end{lstlisting}
+\end{C++}
 &
 \begin{lstlisting}[language=Golang]
@@ -6282 +6271 @@
 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}§
+*?$\R{\textvisiblespace}$*? $\C{// dereference operator, dereference operator}$
+*$\R{\textvisiblespace}$?*? $\C{// dereference, multiplication operator}$
 \end{cfa}
 By default, the first interpretation is selected, which does not yield a meaningful parse.
@@ -6292 +6281 @@
 The ambiguity occurs when the deference operator has no parameters:
 \begin{cfa}
-*?()§\color{red}\textvisiblespace...§ ;
-*?()§\color{red}\textvisiblespace...§(...) ;
+*?()$\R{\textvisiblespace...}$ ;
+*?()$\R{\textvisiblespace...}$(...) ;
 \end{cfa}
 requiring arbitrary whitespace look-ahead for the routine-call parameter-list to disambiguate.
@@ -6301 +6290 @@
 The remaining cases are with the increment/decrement operators and conditional expression, \eg:
 \begin{cfa}
-i++?§\color{red}\textvisiblespace...§(...);
-i?++§\color{red}\textvisiblespace...§(...);
+i++?$\R{\textvisiblespace...}$(...);
+i?++$\R{\textvisiblespace...}$(...);
 \end{cfa}
 requiring arbitrary whitespace look-ahead for the operator parameter-list, even though that interpretation is an incorrect expression (juxtaposed identifiers).
 Therefore, it is necessary to disambiguate these cases with a space:
 \begin{cfa}
-i++§\color{red}\textvisiblespace§? i : 0;
-i?§\color{red}\textvisiblespace§++i : 0;
+i++$\R{\textvisiblespace}$? i : 0;
+i?$\R{\textvisiblespace}$++i : 0;
 \end{cfa}
 
@@ -6321 +6310 @@
 \begin{description}
 \item[Change:] add new keywords \\
-New keywords are added to \CFA (see~\VRef{s:CFAKeywords}).
+New keywords are added to \CFA \see{\VRef{s:CFAKeywords}}.
 \item[Rationale:] keywords added to implement new semantics of \CFA.
 \item[Effect on original feature:] change to semantics of well-defined feature. \\
 Any \Celeven programs using these keywords as identifiers are invalid \CFA programs.
-\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}).
+\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism \see{\VRef{s:BackquoteIdentifiers}}.
 \item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
 \end{description}
@@ -6335 +6324 @@
 \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}$
 {
         ...
@@ -6362 +6351 @@
 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.
@@ -6384 +6373 @@
 \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©.
@@ -6392 +6381 @@
 \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.
@@ -6404 +6393 @@
 \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.
@@ -6412 +6401 @@
 \begin{cfa}
 struct X { int i; struct X *next; };
-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; $\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}$
 \end{cfa}
 \item[Rationale:] avoids having different initialization rules for builtin types and user-defined types.
@@ -6426 +6415 @@
 \item[Change:] have ©struct© introduce a scope for nested types:
 \begin{cfa}
-enum ®Colour® { R, G, B, Y, C, M };
+enum @Colour@ { R, G, B, Y, C, M };
 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)}§
+        enum @Colour@ { R, G, B };      $\C[7cm]{// nested type}$
+        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}§
-Person®.Colour® pc = Person®.®R;§\C{// type/enum defined inside}§
-Person®.®Face pretty; §\C{// type defined inside}\CRT§
+@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$
 \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.
@@ -6455 +6444 @@
 \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;
@@ -6470 +6459 @@
 \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}
 \item[Rationale:] increase type safety
 \item[Effect on original feature:] deletion of semantically well-defined feature.
-\item[Difficulty of converting:] requires adding a cast (see \VRef{s:StorageManagement} for better alternatives):
+\item[Difficulty of converting:] requires adding a cast \see{\VRef{s:StorageManagement} for better alternatives}:
 \begin{cfa}
         int * b = (int *)malloc( sizeof(int) );
@@ -6586 +6575 @@
 \end{cquote}
 For the prescribed head-files, \CFA uses header interposition to wraps these includes in an ©extern "C"©;
-hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
+hence, names in these include files are not mangled\index{mangling!name} \see{\VRef{s:Interoperability}}.
 All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
 This approach is different from \Index*[C++]{\CC{}} where the name-mangling issue is handled internally in C header-files through checks for preprocessor variable ©__cplusplus©, which adds appropriate ©extern "C"© qualifiers.
@@ -6649 +6638 @@
 Type-safe allocation is provided for all C allocation routines and new \CFA allocation routines, \eg in
 \begin{cfa}
-int * ip = (int *)malloc( sizeof(int) );                §\C{// C}§
-int * ip = malloc();                                                    §\C{// \CFA type-safe version of C malloc}§
-int * ip = alloc();                                                             §\C{// \CFA type-safe uniform alloc}§
+int * ip = (int *)malloc( sizeof(int) );                $\C{// C}$
+int * ip = malloc();                                                    $\C{// \CFA type-safe version of C malloc}$
+int * ip = alloc();                                                             $\C{// \CFA type-safe uniform alloc}$
 \end{cfa}
 the latter two allocations determine the allocation size from the type of ©p© (©int©) and cast the pointer to the allocated storage to ©int *©.
@@ -6658 +6647 @@
 \begin{cfa}
 struct S { int i; } __attribute__(( aligned( 128 ) )); // cache-line alignment
-S * sp = malloc();                                                              §\C{// honour type alignment}§
+S * sp = malloc();                                                              $\C{// honour type alignment}$
 \end{cfa}
 the storage allocation is implicitly aligned to 128 rather than the default 16.
@@ -6673 +6662 @@
 \CFA memory management extends allocation to support constructors for initialization of allocated storage, \eg in
 \begin{cfa}
-struct S { int i; };                                                    §\C{// cache-line aglinment}§
+struct S { int i; };                                                    $\C{// cache-line alignment}$
 void ?{}( S & s, int i ) { s.i = i; }
 // assume ?|? operator for printing an S
 
-S & sp = *®new®( 3 );                                                   §\C{// call constructor after allocation}§
+S & sp = *@new@( 3 );                                                   $\C{// call constructor after allocation}$
 sout | sp.i;
-®delete®( &sp );
-
-S * spa = ®anew®( 10, 5 );                                              §\C{// allocate array and initialize each array element}§
+@delete@( &sp );
+
+S * spa = @anew@( 10, 5 );                                              $\C{// allocate array and initialize each array element}$
 for ( i; 10 ) sout | spa[i] | nonl;
 sout | nl;
-®adelete®( 10, spa );
+@adelete@( 10, spa );
 \end{cfa}
 Allocation routines ©new©/©anew© allocate a variable/array and initialize storage using the allocated type's constructor.
@@ -6693 +6682 @@
 extern "C" {
         // C unsafe allocation
-        void * malloc( size_t size );§\indexc{malloc}§
-        void * calloc( size_t dim, size_t size );§\indexc{calloc}§
-        void * realloc( void * ptr, size_t size );§\indexc{realloc}§
-        void * memalign( size_t align, size_t size );§\indexc{memalign}§
-        void * aligned_alloc( size_t align, size_t size );§\indexc{aligned_alloc}§
-        int posix_memalign( void ** ptr, size_t align, size_t size );§\indexc{posix_memalign}§
-        void * cmemalign( size_t alignment, size_t noOfElems, size_t elemSize );§\indexc{cmemalign}§ // CFA
+        void * malloc( size_t size );$\indexc{malloc}$
+        void * calloc( size_t dim, size_t size );$\indexc{calloc}$
+        void * realloc( void * ptr, size_t size );$\indexc{realloc}$
+        void * memalign( size_t align, size_t size );$\indexc{memalign}$
+        void * aligned_alloc( size_t align, size_t size );$\indexc{aligned_alloc}$
+        int posix_memalign( void ** ptr, size_t align, size_t size );$\indexc{posix_memalign}$
+        void * cmemalign( size_t alignment, size_t noOfElems, size_t elemSize );$\indexc{cmemalign}$ // CFA
 
         // C unsafe initialization/copy
-        void * memset( void * dest, int c, size_t size );§\indexc{memset}§
-        void * memcpy( void * dest, const void * src, size_t size );§\indexc{memcpy}§
+        void * memset( void * dest, int c, size_t size );$\indexc{memset}$
+        void * memcpy( void * dest, const void * src, size_t size );$\indexc{memcpy}$
 }
 
@@ -6709 +6698 @@
 
 forall( dtype T | sized(T) ) {
-        // §\CFA§ safe equivalents, i.e., implicit size specification
+        // $\CFA$ safe equivalents, i.e., implicit size specification
         T * malloc( void );
         T * calloc( size_t dim );
@@ -6718 +6707 @@
         int posix_memalign( T ** ptr, size_t align );
 
-        // §\CFA§ safe general allocation, fill, resize, alignment, array
-        T * alloc( void );§\indexc{alloc}§                                      §\C[3.5in]{// variable, T size}§
-        T * alloc( size_t dim );                                                        §\C{// array[dim], T size elements}§
-        T * alloc( T ptr[], size_t dim );                                       §\C{// realloc array[dim], T size elements}§
-
-        T * alloc_set( char fill );§\indexc{alloc_set}§         §\C{// variable, T size, fill bytes with value}§
-        T * alloc_set( T fill );                                                        §\C{// variable, T size, fill with value}§
-        T * alloc_set( size_t dim, char fill );                         §\C{// array[dim], T size elements, fill bytes with value}§
-        T * alloc_set( size_t dim, T fill );                            §\C{// array[dim], T size elements, fill elements with value}§
-        T * alloc_set( size_t dim, const T fill[] );            §\C{// array[dim], T size elements, fill elements with array}§
-        T * alloc_set( T ptr[], size_t dim, char fill );        §\C{// realloc array[dim], T size elements, fill bytes with value}§
-
-        T * alloc_align( size_t align );                                        §\C{// aligned variable, T size}§
-        T * alloc_align( size_t align, size_t dim );            §\C{// aligned array[dim], T size elements}§
-        T * alloc_align( T ptr[], size_t align );                       §\C{// realloc new aligned array}§
-        T * alloc_align( T ptr[], size_t align, size_t dim ); §\C{// realloc new aligned array[dim]}§
-
-        T * alloc_align_set( size_t align, char fill );         §\C{// aligned variable, T size, fill bytes with value}§
-        T * alloc_align_set( size_t align, T fill );            §\C{// aligned variable, T size, fill with value}§
-        T * alloc_align_set( size_t align, size_t dim, char fill ); §\C{// aligned array[dim], T size elements, fill bytes with value}§
-        T * alloc_align_set( size_t align, size_t dim, T fill ); §\C{// aligned array[dim], T size elements, fill elements with value}§
-        T * alloc_align_set( size_t align, size_t dim, const T fill[] ); §\C{// aligned array[dim], T size elements, fill elements with array}§
-        T * alloc_align_set( T ptr[], size_t align, size_t dim, char fill ); §\C{// realloc new aligned array[dim], fill new bytes with value}§
-
-        // §\CFA§ safe initialization/copy, i.e., implicit size specification
-        T * memset( T * dest, char fill );§\indexc{memset}§
-        T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
-
-        // §\CFA§ safe initialization/copy, i.e., implicit size specification, array types
+        // $\CFA$ safe general allocation, fill, resize, alignment, array
+        T * alloc( void );$\indexc{alloc}$                                      $\C[3.5in]{// variable, T size}$
+        T * alloc( size_t dim );                                                        $\C{// array[dim], T size elements}$
+        T * alloc( T ptr[], size_t dim );                                       $\C{// realloc array[dim], T size elements}$
+
+        T * alloc_set( char fill );$\indexc{alloc_set}$         $\C{// variable, T size, fill bytes with value}$
+        T * alloc_set( T fill );                                                        $\C{// variable, T size, fill with value}$
+        T * alloc_set( size_t dim, char fill );                         $\C{// array[dim], T size elements, fill bytes with value}$
+        T * alloc_set( size_t dim, T fill );                            $\C{// array[dim], T size elements, fill elements with value}$
+        T * alloc_set( size_t dim, const T fill[] );            $\C{// array[dim], T size elements, fill elements with array}$
+        T * alloc_set( T ptr[], size_t dim, char fill );        $\C{// realloc array[dim], T size elements, fill bytes with value}$
+
+        T * alloc_align( size_t align );                                        $\C{// aligned variable, T size}$
+        T * alloc_align( size_t align, size_t dim );            $\C{// aligned array[dim], T size elements}$
+        T * alloc_align( T ptr[], size_t align );                       $\C{// realloc new aligned array}$
+        T * alloc_align( T ptr[], size_t align, size_t dim ); $\C{// realloc new aligned array[dim]}$
+
+        T * alloc_align_set( size_t align, char fill );         $\C{// aligned variable, T size, fill bytes with value}$
+        T * alloc_align_set( size_t align, T fill );            $\C{// aligned variable, T size, fill with value}$
+        T * alloc_align_set( size_t align, size_t dim, char fill ); $\C{// aligned array[dim], T size elements, fill bytes with value}$
+        T * alloc_align_set( size_t align, size_t dim, T fill ); $\C{// aligned array[dim], T size elements, fill elements with value}$
+        T * alloc_align_set( size_t align, size_t dim, const T fill[] ); $\C{// aligned array[dim], T size elements, fill elements with array}$
+        T * alloc_align_set( T ptr[], size_t align, size_t dim, char fill ); $\C{// realloc new aligned array[dim], fill new bytes with value}$
+
+        // $\CFA$ safe initialization/copy, i.e., implicit size specification
+        T * memset( T * dest, char fill );$\indexc{memset}$
+        T * memcpy( T * dest, const T * src );$\indexc{memcpy}$
+
+        // $\CFA$ safe initialization/copy, i.e., implicit size specification, array types
         T * amemset( T dest[], char fill, size_t dim );
         T * amemcpy( T dest[], const T src[], size_t dim );
 }
 
-// §\CFA§ allocation/deallocation and constructor/destructor, non-array types
-forall( dtype T | sized(T), ttype Params | { void ?{}( T &, Params ); } ) T * new( Params p );§\indexc{new}§
-forall( dtype T | sized(T) | { void ^?{}( T & ); } ) void delete( T * ptr );§\indexc{delete}§
+// $\CFA$ allocation/deallocation and constructor/destructor, non-array types
+forall( dtype T | sized(T), ttype Params | { void ?{}( T &, Params ); } ) T * new( Params p );$\indexc{new}$
+forall( dtype T | sized(T) | { void ^?{}( T & ); } ) void delete( T * ptr );$\indexc{delete}$
 forall( dtype T, ttype Params | sized(T) | { void ^?{}( T & ); void delete( Params ); } )
   void delete( T * ptr, Params rest );
 
-// §\CFA§ allocation/deallocation and constructor/destructor, array types
-forall( dtype T | sized(T), ttype Params | { void ?{}( T &, Params ); } ) T * anew( size_t dim, Params p );§\indexc{anew}§
-forall( dtype T | sized(T) | { void ^?{}( T & ); } ) void adelete( size_t dim, T arr[] );§\indexc{adelete}§
+// $\CFA$ allocation/deallocation and constructor/destructor, array types
+forall( dtype T | sized(T), ttype Params | { void ?{}( T &, Params ); } ) T * anew( size_t dim, Params p );$\indexc{anew}$
+forall( dtype T | sized(T) | { void ^?{}( T & ); } ) void adelete( size_t dim, T arr[] );$\indexc{adelete}$
 forall( dtype T | sized(T) | { void ^?{}( T & ); }, ttype Params | { void adelete( Params ); } )
   void adelete( size_t dim, T arr[], Params rest );
@@ -6769 +6758 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-int ato( const char * ptr );§\indexc{ato}§
+int ato( const char * ptr );$\indexc{ato}$
 unsigned int ato( const char * ptr );
 long int ato( const char * ptr );
@@ -6801 +6790 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-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{// location}$
+T * bsearch( T key, const T * arr, size_t dim );$\indexc{bsearch}$
+
+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}§
+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}§
+        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}§
+        E * bsearchu( E key, const E * vals, size_t dim );$\indexc{bsearchu}$
         size_t bsearchu( E key, const E * vals, size_t dim );
 }
@@ -6829 +6818 @@
 
 forall( otype E | { int ?<?( E, E ); } ) {
-        void qsort( E * vals, size_t dim );§\indexc{qsort}§
+        void qsort( E * vals, size_t dim );$\indexc{qsort}$
 }
 \end{cfa}
@@ -6838 +6827 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-unsigned char abs( signed char );§\indexc{abs}§
+unsigned char abs( signed char );$\indexc{abs}$
 int abs( int );
 unsigned long int abs( long int );
@@ -6857 +6846 @@
 \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)}§
+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)}§
+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)}§
+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)}§
+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}§
+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}$
 \end{cfa}
 
@@ -6885 +6874 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );§\indexc{min}§
-forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );§\indexc{max}§
-forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
-forall( otype T ) void swap( T * t1, T * t2 );§\indexc{swap}§
+forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );$\indexc{min}$
+forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );$\indexc{max}$
+forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );$\indexc{clamp}$
+forall( otype T ) void swap( T * t1, T * t2 );$\indexc{swap}$
 \end{cfa}
 
@@ -6902 +6891 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-float ?%?( float, float );§\indexc{fmod}§
+float ?%?( float, float );$\indexc{fmod}$
 float fmod( float, float );
 double ?%?( double, double );
@@ -6909 +6898 @@
 long double fmod( long double, long double );
 
-float remainder( float, float );§\indexc{remainder}§
+float remainder( float, float );$\indexc{remainder}$
 double remainder( double, double );
 long double remainder( long double, long double );
 
-float remquo( float, float, int * );§\indexc{remquo}§
+float remquo( float, float, int * );$\indexc{remquo}$
 double remquo( double, double, int * );
 long double remquo( long double, long double, int * );
@@ -6920 +6909 @@
 [ 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 * );
@@ -6927 +6916 @@
 [ int, long double ] div( long double, long double );
 
-float fma( float, float, float );§\indexc{fma}§
+float fma( float, float, float );$\indexc{fma}$
 double fma( double, double, double );
 long double fma( long double, long double, long double );
 
-float fdim( float, float );§\indexc{fdim}§
+float fdim( float, float );$\indexc{fdim}$
 double fdim( double, double );
 long double fdim( long double, long double );
 
-float nan( const char * );§\indexc{nan}§
+float nan( const char * );$\indexc{nan}$
 double nan( const char * );
 long double nan( const char * );
@@ -6945 +6934 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-float exp( float );§\indexc{exp}§
+float exp( float );$\indexc{exp}$
 double exp( double );
 long double exp( long double );
@@ -6952 +6941 @@
 long double _Complex exp( long double _Complex );
 
-float exp2( float );§\indexc{exp2}§
+float exp2( float );$\indexc{exp2}$
 double exp2( double );
 long double exp2( long double );
@@ -6959 +6948 @@
 // long double _Complex exp2( long double _Complex );
 
-float expm1( float );§\indexc{expm1}§
+float expm1( float );$\indexc{expm1}$
 double expm1( double );
 long double expm1( long double );
 
-float pow( float, float );§\indexc{pow}§
+float pow( float, float );$\indexc{pow}$
 double pow( double, double );
 long double pow( long double, long double );
@@ -6976 +6965 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-float log( float );§\indexc{log}§
+float log( float );$\indexc{log}$
 double log( double );
 long double log( long double );
@@ -6983 +6972 @@
 long double _Complex log( long double _Complex );
 
-float log2( float );§\indexc{log2}§
+float log2( float );$\indexc{log2}$
 double log2( double );
 long double log2( long double );
@@ -6990 +6979 @@
 // long double _Complex log2( long double _Complex );
 
-float log10( float );§\indexc{log10}§
+float log10( float );$\indexc{log10}$
 double log10( double );
 long double log10( long double );
@@ -6997 +6986 @@
 // long double _Complex log10( long double _Complex );
 
-float log1p( float );§\indexc{log1p}§
+float log1p( float );$\indexc{log1p}$
 double log1p( double );
 long double log1p( long double );
 
-int ilogb( float );§\indexc{ilogb}§
+int ilogb( float );$\indexc{ilogb}$
 int ilogb( double );
 int ilogb( long double );
 
-float logb( float );§\indexc{logb}§
+float logb( float );$\indexc{logb}$
 double logb( double );
 long double logb( long double );
 
-float sqrt( float );§\indexc{sqrt}§
+float sqrt( float );$\indexc{sqrt}$
 double sqrt( double );
 long double sqrt( long double );
@@ -7016 +7005 @@
 long double _Complex sqrt( long double _Complex );
 
-float cbrt( float );§\indexc{cbrt}§
+float cbrt( float );$\indexc{cbrt}$
 double cbrt( double );
 long double cbrt( long double );
 
-float hypot( float, float );§\indexc{hypot}§
+float hypot( float, float );$\indexc{hypot}$
 double hypot( double, double );
 long double hypot( long double, long double );
@@ -7030 +7019 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-float sin( float );§\indexc{sin}§
+float sin( float );$\indexc{sin}$
 double sin( double );
 long double sin( long double );
@@ -7037 +7026 @@
 long double _Complex sin( long double _Complex );
 
-float cos( float );§\indexc{cos}§
+float cos( float );$\indexc{cos}$
 double cos( double );
 long double cos( long double );
@@ -7044 +7033 @@
 long double _Complex cos( long double _Complex );
 
-float tan( float );§\indexc{tan}§
+float tan( float );$\indexc{tan}$
 double tan( double );
 long double tan( long double );
@@ -7051 +7040 @@
 long double _Complex tan( long double _Complex );
 
-float asin( float );§\indexc{asin}§
+float asin( float );$\indexc{asin}$
 double asin( double );
 long double asin( long double );
@@ -7058 +7047 @@
 long double _Complex asin( long double _Complex );
 
-float acos( float );§\indexc{acos}§
+float acos( float );$\indexc{acos}$
 double acos( double );
 long double acos( long double );
@@ -7065 +7054 @@
 long double _Complex acos( long double _Complex );
 
-float atan( float );§\indexc{atan}§
+float atan( float );$\indexc{atan}$
 double atan( double );
 long double atan( long double );
@@ -7072 +7061 @@
 long double _Complex atan( long double _Complex );
 
-float atan2( float, float );§\indexc{atan2}§
+float atan2( float, float );$\indexc{atan2}$
 double atan2( double, double );
 long double atan2( long double, long double );
 
-float atan( float, float ); §\C{// alternative name for atan2}§
-double atan( double, double );§\indexc{atan}§
+float atan( float, float ); $\C{// alternative name for atan2}$
+double atan( double, double );$\indexc{atan}$
 long double atan( long double, long double );
 \end{cfa}
@@ -7086 +7075 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-float sinh( float );§\indexc{sinh}§
+float sinh( float );$\indexc{sinh}$
 double sinh( double );
 long double sinh( long double );
@@ -7093 +7082 @@
 long double _Complex sinh( long double _Complex );
 
-float cosh( float );§\indexc{cosh}§
+float cosh( float );$\indexc{cosh}$
 double cosh( double );
 long double cosh( long double );
@@ -7100 +7089 @@
 long double _Complex cosh( long double _Complex );
 
-float tanh( float );§\indexc{tanh}§
+float tanh( float );$\indexc{tanh}$
 double tanh( double );
 long double tanh( long double );
@@ -7107 +7096 @@
 long double _Complex tanh( long double _Complex );
 
-float asinh( float );§\indexc{asinh}§
+float asinh( float );$\indexc{asinh}$
 double asinh( double );
 long double asinh( long double );
@@ -7114 +7103 @@
 long double _Complex asinh( long double _Complex );
 
-float acosh( float );§\indexc{acosh}§
+float acosh( float );$\indexc{acosh}$
 double acosh( double );
 long double acosh( long double );
@@ -7121 +7110 @@
 long double _Complex acosh( long double _Complex );
 
-float atanh( float );§\indexc{atanh}§
+float atanh( float );$\indexc{atanh}$
 double atanh( double );
 long double atanh( long double );
@@ -7134 +7123 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-float erf( float );§\indexc{erf}§
+float erf( float );$\indexc{erf}$
 double erf( double );
 long double erf( long double );
@@ -7141 +7130 @@
 long double _Complex erf( long double _Complex );
 
-float erfc( float );§\indexc{erfc}§
+float erfc( float );$\indexc{erfc}$
 double erfc( double );
 long double erfc( long double );
@@ -7148 +7137 @@
 long double _Complex erfc( long double _Complex );
 
-float lgamma( float );§\indexc{lgamma}§
+float lgamma( float );$\indexc{lgamma}$
 double lgamma( double );
 long double lgamma( long double );
@@ -7155 +7144 @@
 long double lgamma( long double, int * );
 
-float tgamma( float );§\indexc{tgamma}§
+float tgamma( float );$\indexc{tgamma}$
 double tgamma( double );
 long double tgamma( long double );
@@ -7165 +7154 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-float floor( float );§\indexc{floor}§
+float floor( float );$\indexc{floor}$
 double floor( double );
 long double floor( long double );
 
-float ceil( float );§\indexc{ceil}§
+float ceil( float );$\indexc{ceil}$
 double ceil( double );
 long double ceil( long double );
 
-float trunc( float );§\indexc{trunc}§
+float trunc( float );$\indexc{trunc}$
 double trunc( double );
 long double trunc( long double );
 
-float rint( float );§\indexc{rint}§
+float rint( float );$\indexc{rint}$
 long double rint( long double );
 long int rint( float );
@@ -7186 +7175 @@
 long long int rint( long double );
 
-long int lrint( float );§\indexc{lrint}§
+long int lrint( float );$\indexc{lrint}$
 long int lrint( double );
 long int lrint( long double );
@@ -7193 +7182 @@
 long long int llrint( long double );
 
-float nearbyint( float );§\indexc{nearbyint}§
+float nearbyint( float );$\indexc{nearbyint}$
 double nearbyint( double );
 long double nearbyint( long double );
 
-float round( float );§\indexc{round}§
+float round( float );$\indexc{round}$
 long double round( long double );
 long int round( float );
@@ -7206 +7195 @@
 long long int round( long double );
 
-long int lround( float );§\indexc{lround}§
+long int lround( float );$\indexc{lround}$
 long int lround( double );
 long int lround( long double );
@@ -7219 +7208 @@
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-float copysign( float, float );§\indexc{copysign}§
+float copysign( float, float );$\indexc{copysign}$
 double copysign( double, double );
 long double copysign( long double, long double );
 
-float frexp( float, int * );§\indexc{frexp}§
+float frexp( float, int * );$\indexc{frexp}$
 double frexp( double, int * );
 long double frexp( long double, int * );
 
-float ldexp( float, int );§\indexc{ldexp}§
+float ldexp( float, int );$\indexc{ldexp}$
 double ldexp( double, int );
 long double ldexp( long double, int );
 
-[ float, float ] modf( float );§\indexc{modf}§
+[ float, float ] modf( float );$\indexc{modf}$
 float modf( float, float * );
 [ double, double ] modf( double );
@@ -7238 +7227 @@
 long double modf( long double, long double * );
 
-float nextafter( float, float );§\indexc{nextafter}§
+float nextafter( float, float );$\indexc{nextafter}$
 double nextafter( double, double );
 long double nextafter( long double, long double );
 
-float nexttoward( float, long double );§\indexc{nexttoward}§
+float nexttoward( float, long double );$\indexc{nexttoward}$
 double nexttoward( double, long double );
 long double nexttoward( long double, long double );
 
-float scalbn( float, int );§\indexc{scalbn}§
+float scalbn( float, int );$\indexc{scalbn}$
 double scalbn( double, int );
 long double scalbn( long double, int );
 
-float scalbln( float, long int );§\indexc{scalbln}§
+float scalbln( float, long int );$\indexc{scalbln}$
 double scalbln( double, long int );
 long double scalbln( long double, long int );
@@ -7267 +7256 @@
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 struct Duration {
-        int64_t tv; §\C{// nanoseconds}§
+        int64_t tv; $\C{// nanoseconds}$
 };
 
@@ -7397 +7386 @@
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 struct Time {
-        uint64_t tv; §\C{// nanoseconds since UNIX epoch}§
+        uint64_t tv; $\C{// nanoseconds since UNIX epoch}$
 };
 
@@ -7468 +7457 @@
 \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}$
 };
 
@@ -7477 +7466 @@
 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 getResNsec(); $\C{// with nanoseconds}$
+Duration getRes(); $\C{// without nanoseconds}$
+
+Time getTimeNsec(); $\C{// with nanoseconds}$
+Time getTime(); $\C{// without nanoseconds}$
 Time getTime( Clock & clk );
 Time ?()( Clock & clk );
@@ -7497 +7486 @@
 
 \begin{cfa}
-void ?{}( Int * this ); §\C{// constructor/destructor}§
+void ?{}( Int * this ); $\C{// constructor/destructor}$
 void ?{}( Int * this, Int init );
 void ?{}( Int * this, zero_t );
@@ -7506 +7495 @@
 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 );
@@ -7523 +7512 @@
 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 );
@@ -7559 +7548 @@
 int ?>=?( unsigned long int oper1, Int oper2 );
 
-Int +?( Int oper ); §\C{// arithmetic}§
+Int +?( Int oper ); $\C{// arithmetic}$
 Int -?( Int oper );
 Int ~?( Int oper );
@@ -7641 +7630 @@
 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 );
@@ -7653 +7642 @@
 Int sqrt( Int oper );
 
-forall( dtype istype | istream( istype ) ) istype * ?|?( istype * is, Int * mp );  §\C{// I/O}§
+forall( dtype istype | istream( istype ) ) istype * ?|?( istype * is, Int * mp );  $\C{// I/O}$
 forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype * os, Int mp );
 \end{cfa}
@@ -7664 +7653 @@
 \hline
 \begin{cfa}
-#include <gmp>§\indexc{gmp}§
+#include <gmp>$\indexc{gmp}$
 int main( void ) {
         sout | "Factorial Numbers";
@@ -7678 +7667 @@
 &
 \begin{cfa}
-#include <gmp.h>§\indexc{gmp.h}§
+#include <gmp.h>$\indexc{gmp.h}$
 int main( void ) {
-        ®gmp_printf®( "Factorial Numbers\n" );
-        ®mpz_t® fact;
-        ®mpz_init_set_ui®( fact, 1 );
-        ®gmp_printf®( "%d %Zd\n", 0, fact );
+        @gmp_printf@( "Factorial Numbers\n" );
+        @mpz_t@ fact;
+        @mpz_init_set_ui@( fact, 1 );
+        @gmp_printf@( "%d %Zd\n", 0, fact );
         for ( unsigned int i = 1; i <= 40; i += 1 ) {
-                ®mpz_mul_ui®( fact, fact, i );
-                ®gmp_printf®( "%d %Zd\n", i, fact );
+                @mpz_mul_ui@( fact, fact, i );
+                @gmp_printf@( "%d %Zd\n", i, fact );
         }
 }
@@ -7751 +7740 @@
 \begin{cfa}[belowskip=0pt]
 // implementation
-struct Rational {§\indexc{Rational}§
-        long int numerator, denominator; §\C{// invariant: denominator > 0}§
+struct Rational {$\indexc{Rational}$
+        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 );
@@ -7761 +7750 @@
 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 );
@@ -7773 +7762 @@
 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 );
@@ -7779 +7768 @@
 Rational ?/?( Rational l, Rational r );
 
-double widen( Rational r ); §\C{// conversion}§
+double widen( Rational r ); $\C{// conversion}$
 Rational narrow( double f, long int md );