Changes in doc/user/user.tex [0638c44:6e991d6]

File:

• doc/user/user.tex (modified) (87 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 : Tue May  3 08:05:33 2016
-%% Update Count     : 246
+%% Last Modified On : Thu Apr 21 08:15:37 2016
+%% Update Count     : 131
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 % requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
-
-% inline code ©...© (copyright symbol) emacs: C-q M-)
-% red highlighting ®...® (registered trademark sumbol) emacs: C-q M-.
-% latex escape §...§ (section symbol) emacs: C-q M-'
-% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
-% math escape $...$ (dollar symbol)
 
 \documentclass[openright,twoside]{article}
@@ -180 +174 @@
 \CC~\cite{c++,ANSI14:C++} is an example of a similar project;
 however, it largely extended the language, and did not address 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.}
+Two important existing problems addressed were changing the type of character literals from \lstinline@int@ to \lstinline@char@ and enumerator from \lstinline@int@ to the type of its enumerators.}
 Fortran~\cite{Fortran08}, Ada~\cite{Ada12}, and Cobol~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features are added and problems fixed within the framework of the existing language.
 Java~\cite{Java8}, Go~\cite{Go}, Rust~\cite{Rust} and D~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
@@ -205 +199 @@
 
 However, it is necessary to differentiate between C and \CFA code because of name overloading, as for \CC.
-For example, the C math-library provides the following routines for computing the absolute value of the basic type: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©.
-Whereas, \CFA wraps each of these routines into one with the common name ©abs©.
+For example, the C math-library provides the following routines for computing the absolute value of the basic type: \lstinline@abs@, \lstinline@labs@, \lstinline@llabs@, \lstinline@fabs@, \lstinline@fabsf@, \lstinline@fabsl@, \lstinline@cabsf@, \lstinline@cabs@, and \lstinline@cabsl@.
+Whereas, \CFA wraps each of these routines into one with the common name \lstinline@abs@.
 \begin{lstlisting}
 char abs( char );
@@ -221 +215 @@
 long double _Complex abs( long double _Complex );
 \end{lstlisting}
-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}.
+The problem is the name clash between the library routine \lstinline@abs@ and the \CFA names \lstinline@abs@.
+Hence, names appearing in an \lstinline@extern "C"@ block have \newterm{C linkage}.
 Then overloading polymorphism uses a mechanism called \newterm{name mangling} 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 type.
 This example strongly illustrates a core idea in \CFA: \emph{the 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© should be sufficient to apply it to any type where it is applicable.
+The name ``\lstinline@abs@'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
+Hence, knowing the name \lstinline@abs@ should be sufficient to apply it to any type where it is applicable.
 The time savings and safety of using one name uniformly versus $N$ unique names should not be underestimated.
 
 
-\section[Compiling CFA Program]{Compiling \CFA Program}
-
-The command ©cfa© is used to compile \CFA program(s).
-This command works like the GNU ©gcc©\index{gcc} command, e.g.:
-\begin{lstlisting}
-cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
-\end{lstlisting}
-By default, \CFA programs having the following ©gcc© flags turned on:
+\section{Compiling \CFA Program}
+
+The command \lstinline@cfa@ is used to compile \CFA program(s).
+This command works like the GNU \lstinline@gcc@\index{gcc} command, e.g.:
+\begin{lstlisting}
+cfa [ gcc-options ] C/@{\CFA}@-files [ assembler/loader-files ]
+\end{lstlisting}
+\index{cfa@\lstinline$cfa$}\index{compilation!cfa@\lstinline$cfa$}
+By default, \CFA programs having the following \lstinline@gcc@ flags turned on:
 \begin{description}
-\item\hspace*{-4pt}\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
+\item
+\hspace*{-4pt}\lstinline@-std=gnu99@
+\index{-std=gnu99@{\lstinline$-std=gnu99$}}\index{compilation option!-std=gnu99@{\lstinline$-std=gnu99$}}
 The 1999 C standard plus GNU extensions.
-\item\hspace*{-4pt}\Indexc{-fgnu89-¶inline¶}\index{compilation option!-fgnu89-inline@{©-fgnu89-¶inline¶©}}
+\item
+\hspace*{-4pt}\lstinline@-fgnu89-inline@
+\index{-fgnu89-inline@{\lstinline$-fgnu89-inline$}}\index{compilation option!-fgnu89-inline@{\lstinline$-fgnu89-inline$}}
 Use the traditional GNU semantics for inline routines in C99 mode.
 \end{description}
 The following new \CFA option is available:
 \begin{description}
-\item\hspace*{-4pt}\Indexc{-CFA}\index{compilation option!-CFA@{©-CFA©}}
+\item
+\hspace*{-4pt}\lstinline@-CFA@
+\index{-CFA@{\lstinline$-CFA$}}\index{compilation option!-CFA@{\lstinline$-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.
 \end{description}
@@ -254 +255 @@
 The following preprocessor variables are available:
 \begin{description}
-\item\hspace*{-4pt}\Indexc{__CFA__}\index{preprocessor variables!__CFA__@{©__CFA__©}}
+\item
+\hspace*{-4pt}\lstinline$__CFA__$
+\index{__CFA__@{\lstinline$__CFA__$}}\index{preprocessor variables!__CFA__@{\lstinline$__CFA__$}}
 is always available during preprocessing and its value is the current major \Index{version number} of \CFA.\footnote{
 The C preprocessor allows only integer values in a preprocessor variable so a value like ``\Version'' is not allowed.
 Hence, the need to have three variables for the major, minor and patch version number.}
 
-\item\hspace*{-4pt}\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{©__CFA_MINOR__©}}
+\item
+\hspace*{-4pt}\lstinline$__CFA_MINOR__$
+\index{__CFA_MINOR__@{\lstinline$__CFA_MINOR__$}}\index{preprocessor variables!__CFA_MINOR__@{\lstinline$__CFA_MINOR__$}}
 is always available during preprocessing and its value is the current minor \Index{version number} of \CFA.
 
-\item\hspace*{-4pt}\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@©__CFA_PATCH__©}
+\item
+\hspace*{-4pt}\lstinline$__CFA_PATCH__$
+\index{__CFA_PATCH__@%(__CFA_PATCH__%)}\index{preprocessor variables!__CFA_PATCH__@%(__CFA_PATCH__%)}
 is always available during preprocessing and its value is the current patch \Index{version number} of \CFA.
 
-\item\hspace*{-4pt}\Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@©__CFORALL__©}
+\item
+\hspace*{-4pt}\lstinline$__CFORALL__$
+\index{__CFORALL__@%(__CFORALL__%)}\index{preprocessor variables!__CFORALL__@%(__CFORALL__%)}
 is always available during preprocessing and it has no value.
 \end{description}
@@ -273 +282 @@
 \begin{lstlisting}
 #ifndef __CFORALL__
-#include <stdio.h>                      // C header file
+#include <stdio.h>              // C header file
 #else
-#include <fstream>                      // §\CFA{}§ header file
+#include <fstream>              // @\CFA{}@ header file
 #endif
 \end{lstlisting}
-which conditionally includes the correct header file, if the program is compiled using ©gcc© or ©cfa©. 
+which conditionally includes the correct header file, if the program is compiled using \lstinline@gcc@ or \lstinline@cfa@. 
 
 
@@ -285 +294 @@
 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, e.g.:
 \begin{lstlisting}
-2®_®147®_®483®_®648;                            // decimal constant
+2`_`147`_`483`_`648;                            // decimal constant
 56_ul;                                          // decimal unsigned long constant
 0_377;                                          // octal constant
@@ -299 +308 @@
 \begin{enumerate}
 \item
-A sequence of underscores is disallowed, e.g., ©12__34© is invalid.
+A sequence of underscores is disallowed, e.g., \lstinline@12__34@ is invalid.
 \item
 Underscores may only appear within a sequence of digits (regardless of the digit radix).
-In other words, an underscore cannot start or end a sequence of digits, e.g., ©_1©, ©1_© and ©_1_© are invalid (actually, the 1st and 3rd examples are identifier names).
+In other words, an underscore cannot start or end a sequence of digits, e.g., \lstinline@_1@, \lstinline@1_@ and \lstinline@_1_@ are invalid (actually, the 1st and 3rd examples are identifier names).
 \item
 A numeric prefix may end with an underscore;
 a numeric infix may begin and/or end with an underscore;
 a numeric suffix may begin with an underscore.
-For example, the octal ©0© or hexadecimal ©0x© prefix may end with an underscore ©0_377© or ©0x_ff©;
-the exponent infix ©E© may start or end with an underscore ©1.0_E10©, ©1.0E_10© or ©1.0_E_10©;
-the type suffixes ©U©, ©L©, etc. may start with an underscore ©1_U©, ©1_ll© or ©1.0E10_f©.
+For example, the octal \lstinline@0@ or hexadecimal \lstinline@0x@ prefix may end with an underscore \lstinline@0_377@ or \lstinline@0x_ff@;
+the exponent infix \lstinline@E@ may start or end with an underscore \lstinline@1.0_E10@, \lstinline@1.0E_10@ or \lstinline@1.0_E_10@;
+the type suffixes \lstinline@U@, \lstinline@L@, etc. may start with an underscore \lstinline@1_U@, \lstinline@1_ll@ or \lstinline@1.0E10_f@.
 \end{enumerate}
 It is significantly easier to read and enter long constants when they are broken up into smaller groupings (most cultures use comma or period among digits for the same purpose).
@@ -344 +353 @@
 C and the new \CFA declarations may appear together in the same program block, but cannot be mixed within a specific declaration.
 
-In \CFA declarations, the same tokens are used as in C: the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array, and parentheses ©()© are used to indicate a routine parameter.
+In \CFA declarations, the same tokens are used as in C: the character \lstinline@*@ is used to indicate a pointer, square brackets \lstinline@[@\,\lstinline@]@ are used to represent an array, and parentheses \lstinline@()@ are used to indicate a routine parameter.
 However, unlike C, \CFA type declaration tokens are specified from left to right and the entire type specification is distributed across all variables in the declaration list.
-For instance, variables ©x© and ©y© of type pointer to integer are defined in \CFA as follows:
+For instance, variables \lstinline@x@ and \lstinline@y@ of type pointer to integer are defined in \CFA as follows:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{lstlisting}
-®* int x, y;®
+`* int x, y;`
 \end{lstlisting}
 &
@@ -398 +407 @@
 \end{quote2}
 
-All type qualifiers, i.e., ©const© and ©volatile©, are used in the normal way with the new declarations but appear left to right, e.g.:
+All type qualifiers, i.e., \lstinline@const@ and \lstinline@volatile@, are used in the normal way with the new declarations but appear left to right, e.g.:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
@@ -418 +427 @@
 \end{tabular}
 \end{quote2}
-All declaration qualifiers, i.e., ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
+All declaration qualifiers, i.e., \lstinline@extern@, \lstinline@static@, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} e.g.:
 \begin{quote2}
@@ -440 +449 @@
 \end{quote2}
 
-Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified\footnote{
+Unsupported are K\&R C declarations where the base type defaults to \lstinline@int@, if no type is specified\footnote{
 At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}},
 e.g.:
@@ -457 +466 @@
 \section{Type Operators}
 
-The new declaration syntax can be used in other contexts where types are required, e.g., casts and the pseudo-routine ©sizeof©:
+The new declaration syntax can be used in other contexts where types are required, e.g., casts and the pseudo-routine \lstinline@sizeof@:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
@@ -479 +488 @@
 The point of the new syntax is to allow returning multiple values from a routine~\cite{CLU,Galletly96}, e.g.:
 \begin{lstlisting}
-®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
-        §\emph{routine body}§
-}
-\end{lstlisting}
-where routine ©f© has three output (return values) and three input parameters.
+`[ int o1, int o2, char o3 ]` f( int i1, char i2, char i3 ) {
+        @\emph{routine body}@
+}
+\end{lstlisting}
+where routine \lstinline@f@ has three output (return values) and three input parameters.
 Existing C syntax cannot be extended with multiple return types because it is impossible to embed a single routine name within multiple return type specifications.
 
-In detail, the brackets, ©[]©, enclose the result type, where each return value is named and that name is a local variable of the particular return type.\footnote{
+In detail, the brackets, \lstinline@[]@, enclose the result type, where each return value is named and that name is a local variable of the particular return type.\footnote{
 Michael Tiemann, with help from Doug Lea, provided named return values in g++, circa 1989.}
 The value of each local return variable is automatically returned at routine termination.
 Declaration qualifiers can only appear at the start of a routine definition, e.g.:
 \begin{lstlisting}
-extern [ int x ] g( int y ) {§\,§}
+extern [ int x ] g( int y ) {@\,@}
 \end{lstlisting}
 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{lstlisting}
-[§\,§] g();                                             // no input or output parameters
+[@\,@] g(@\,@);                         // no input or output parameters
 [ void ] g( void );                     // no input or output parameters
 \end{lstlisting}
@@ -510 +519 @@
 int (*f(x))[ 5 ] int x; {}
 \end{lstlisting}
-The string ``©int (*f(x))[ 5 ]©'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``©[ 5 ] int x©'' declares a \CFA style parameter x of type array of 5 integers.
-Since the strings overlap starting with the open bracket, ©[©, there is an ambiguous interpretation for the string.
+The string ``\lstinline@int (*f(x))[ 5 ]@'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``\lstinline@[ 5 ] int x@'' declares a \CFA style parameter x of type array of 5 integers.
+Since the strings overlap starting with the open bracket, \lstinline@[@, there is an ambiguous interpretation for the string.
 As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity:
 \begin{lstlisting}
@@ -517 +526 @@
 int f( int (* foo) );           // foo is redefined as a parameter name
 \end{lstlisting}
-The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
-The redefinition of a type name in a parameter list is the only context in C where the character ©*© can appear to the left of a type name, and \CFA relies on all type modifier characters appearing to the right of the type name.
+The string ``\lstinline@int (* foo)@'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
+The redefinition of a type name in a parameter list is the only context in C where the character \lstinline@*@ can appear to the left of a type name, and \CFA relies on all type modifier characters appearing to the right of the type name.
 The inability to use \CFA declarations in these two contexts is probably a blessing because it precludes programmers from arbitrarily switching between declarations forms within a declaration contexts.
 
@@ -537 +546 @@
 \subsection{Returning Values}
 
-Named return values handle the case where it is necessary to define a local variable whose value is then returned in a ©return© statement, as in:
+Named return values handle the case where it is necessary to define a local variable whose value is then returned in a \lstinline@return@ statement, as in:
 \begin{lstlisting}
 int f() {
@@ -545 +554 @@
 }
 \end{lstlisting}
-Because the value in the return variable is automatically returned when a \CFA routine terminates, the ©return© statement \emph{does not} contain an expression, as in:
-\begin{lstlisting}
-®[ int x ]® f() {
+Because the value in the return variable is automatically returned when a \CFA routine terminates, the \lstinline@return@ statement \emph{does not} contain an expression, as in:
+\begin{lstlisting}
+`[ int x ]` f() {
         ... x = 0; ... x = y; ...
-        ®return;® // implicitly return x
-}
-\end{lstlisting}
-When the return is encountered, the current value of ©x© is returned to the calling routine.
-As well, ``falling off the end'' of a routine without a ©return© statement is permitted, as in:
+        `return;` // implicitly return x
+}
+\end{lstlisting}
+When the return is encountered, the current value of \lstinline@x@ is returned to the calling routine.
+As well, ``falling off the end'' of a routine without a \lstinline@return@ statement is permitted, as in:
 \begin{lstlisting}
 [ int x ] f() {
@@ -559 +568 @@
 } // implicitly return x
 \end{lstlisting}
-In this case, the current value of ©x© is returned to the calling routine just as if a ©return© had been encountered.
+In this case, the current value of \lstinline@x@ is returned to the calling routine just as if a \lstinline@return@ had been encountered.
 
 
@@ -772 +781 @@
 \subsection{Type Nesting}
 
-\CFA allows \Index{type nesting}, and type qualification of the nested types, 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, where as C hoists\index{type!hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l|l@{}}
@@ -827 +836 @@
 
 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{lstlisting}
 \end{tabular}
 \end{quote2}
-In the left example in C, types ©C©, ©U© and ©T© are implicitly hoisted outside of type ©S© into the containing block scope.
-In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``©.©'' for type qualification, as does Java, rather than the \CC type-selection operator ``©::©''.
+In the left example in C, types \lstinline@C@, \lstinline@U@ and \lstinline@T@ are implicitly hoisted outside of type \lstinline@S@ into the containing block scope.
+In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``\lstinline@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``\lstinline@::@''.
 
 
@@ -854 +863 @@
 qsort( ia, size );              // sort ascending order using builtin ?<?
 {
-        ®int ?<?( int x, int y ) { return x > y; }® // nested routine
+        `int ?<?( int x, int y ) { return x > y; }` // nested routine
         qsort( ia, size );      // sort descending order by local redefinition
 }
@@ -861 +870 @@
 Nested routines are not first-class, meaning a nested routine cannot be returned if it has references to variables in its enclosing blocks;
 the only exception is references to the external block of the translation unit, as these variables persist for the duration of the program.
-The following program in undefined in \CFA (and ©gcc©\index{gcc})
+The following program in undefined in \CFA (and \lstinline@gcc@\index{gcc})
 \begin{lstlisting}
 [* [int]( int )] foo() {                // int (*foo())( int )
-        int ®i® = 7;
+        int `i` = 7;
         int bar( int p ) {
-                ®i® += 1;                                       // dependent on local variable
-                sout | ®i® | endl;
+                `i` += 1;                                       // dependent on local variable
+                sout | `i` | endl;
         }
         return bar;                                     // undefined because of local dependence
@@ -888 +897 @@
 The general syntax of a tuple is:
 \begin{lstlisting}
-[ §\emph{exprlist}§ ]
-\end{lstlisting}
-where ©$\emph{exprlist}$© is a list of one or more expressions separated by commas.
-The brackets, ©[]©, allow differentiating between tuples and expressions containing the C comma operator.
+[ $\emph{exprlist}$ ]
+\end{lstlisting}
+where \lstinline@$\emph{exprlist}$@ is a list of one or more expressions separated by commas.
+The brackets, \lstinline$[]$, allow differentiating between tuples and expressions containing the C comma operator.
 The following are examples of tuples:
 \begin{lstlisting}
@@ -898 +907 @@
 [ v+w, x*y, 3.14159, f() ]
 \end{lstlisting}
-Tuples are permitted to contain sub-tuples (i.e., nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.
+Tuples are permitted to contain sub-tuples (i.e., nesting), such as \lstinline@[ [ 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).
@@ -908 +917 @@
 The general syntax of a tuple type is:
 \begin{lstlisting}
-[ §\emph{typelist}§ ]
-\end{lstlisting}
-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.
+[ @\emph{typelist}@ ]
+\end{lstlisting}
+where \lstinline@$\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.
 Examples of tuple types include:
 \begin{lstlisting}
@@ -918 +927 @@
 [ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ]
 \end{lstlisting}
-Like tuples, tuple types may be nested, such as ©[ [ int, int ], int ]©, which is a 2-element tuple type whose first element is itself a tuple type.
+Like tuples, tuple types may be nested, such as \lstinline@[ [ int, int ], int ]@, which is a 2-element tuple type whose first element is itself a tuple type.
 
 Examples of declarations using tuple types are:
@@ -954 +963 @@
 tuple does not have structure like a record; a tuple is simply converted into a list of components.
 \begin{rationale}
-The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; i.e., a statement such as ©g( f() )© is not supported.
+The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; i.e., a statement such as \lstinline@g( f() )@ is not supported.
 Using a temporary variable to store the  results of the inner routine and then passing this variable to the outer routine works, however.
 \end{rationale}
@@ -983 +992 @@
 \begin{rationale}
 Unfortunately, C's syntax for subscripts precluded treating them as tuples.
-The C subscript list has the form ©[i][j]...© and not ©[i, j, ...]©.
-Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, e.g., ©f[g()]© always means a single subscript value because there is only one set of brackets.
-Fixing this requires a major change to C because the syntactic form ©M[i, j, k]© already has a particular meaning: ©i, j, k© is a comma expression.
+The C subscript list has the form \lstinline@[i][j]...@ and not \lstinline@i, j, ...]@.
+Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, e.g., \lstinline@f[g()]@ always means a single subscript value because there is only one set of brackets.
+Fixing this requires a major change to C because the syntactic form \lstinline@M[i, j, k]@ already has a particular meaning: \lstinline@i, j, k@ is a comma expression.
 \end{rationale}
 
@@ -1004 +1013 @@
 [ a, b, c, d ] = w
 \end{lstlisting}
-©w© is implicitly opened to yield a tuple of four values, which are then assigned individually.
+\lstinline@w@ is implicitly opened to yield a tuple of four values, which are then assigned individually.
 
 A \newterm{flattening coercion} coerces a nested tuple, i.e., a tuple with one or more components, which are themselves tuples, into a flattened tuple, which is a tuple whose components are not tuples, as in:
@@ -1012 +1021 @@
 First the right-hand tuple is flattened and then the values are assigned individually.
 Flattening is also performed on tuple types.
-For example, the type ©[ int, [ int, int ], int ]© can be coerced, using flattening, into the type ©[ int, int, int, int ]©.
+For example, the type \lstinline@[ int, [ int, int ], int ]@ can be coerced, using flattening, into the type \lstinline@[ int, int, int, int ]@.
 
 A \newterm{structuring coercion} is the opposite of flattening;
 a tuple is structured into a more complex nested tuple.
-For example, structuring the tuple ©[ 1, 2, 3, 4 ]© into the tuple ©[ 1, [ 2, 3 ], 4 ]© or the tuple type ©[ int, int, int, int ]© into the tuple type ©[ int, [ int, int ], int ]©.
+For example, structuring the tuple \lstinline@[ 1, 2, 3, 4 ]@ into the tuple \lstinline@[ 1, [ 2, 3 ], 4 ]@ or the tuple type \lstinline@[ int, int, int, int ]@ into the tuple type \lstinline@[ int, [ int, int ], int ]@.
 In the following example, the last assignment illustrates all the tuple coercions:
 \begin{lstlisting}
@@ -1024 +1033 @@
 \end{lstlisting}
 Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values;
-therefore, the right-hand tuple is now the tuple ©[ [ 1, 2, 3, 4 ], 5 ]©.
-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).
+therefore, the right-hand tuple is now the tuple \lstinline@[ [ 1, 2, 3, 4 ], 5 ]@.
+This tuple is then flattened, yielding \lstinline@[ 1, 2, 3, 4, 5 ]@, which is structured into \lstinline@[ 1, [ 2, 3, 4, 5 ] ]@ to match the tuple type of the left-hand side.
+The tuple \lstinline@[ 2, 3, 4, 5 ]@ is then closed to create a tuple value.
+Finally, \lstinline@x@ is assigned \lstinline@1@ and \lstinline@w@ is assigned the tuple value using multiple assignment (see Section 14).
 \begin{rationale}
 A possible additional language extension is to use the structuring coercion for tuples to initialize a complex record with a tuple.
@@ -1038 +1047 @@
 Mass assignment has the following form:
 \begin{lstlisting}
-[ §\emph{lvalue}§, ..., §\emph{lvalue}§ ] = §\emph{expr}§;
-\end{lstlisting}
-The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, i.e., any data object that can appear on the left-hand side of a conventional assignment statement.
-©$\emph{expr}$© is any standard arithmetic expression.
+[ @\emph{lvalue}@, ..., @\emph{lvalue}@ ] = @\emph{expr}@;
+\end{lstlisting}
+The left-hand side is a tuple of \lstinline@$\emph{lvalues}$@, which is a list of expressions each yielding an address, i.e., any data object that can appear on the left-hand side of a conventional assignment statement.
+\lstinline@$\emph{expr}$@ is any standard arithmetic expression.
 Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
 
@@ -1067 +1076 @@
 *a1 = t; *a2 = t; *a3 = t;
 \end{lstlisting}
-The temporary ©t© is necessary to store the value of the expression to eliminate conversion issues.
+The temporary \lstinline@t@ is necessary to store the value of the expression to eliminate conversion issues.
 The temporaries for the addresses are needed so that locations on the left-hand side do not change as the values are assigned.
-In this case, ©y[i]© uses the previous value of ©i© and not the new value set at the beginning of the mass assignment.
+In this case, \lstinline@y[i]@ uses the previous value of \lstinline@i@ and not the new value set at the beginning of the mass assignment.
 
 
@@ -1077 +1086 @@
 Multiple assignment has the following form:
 \begin{lstlisting}
-[ §\emph{lvalue}§, . . ., §\emph{lvalue}§ ] = [ §\emph{expr}§, . . ., §\emph{expr}§ ];
-\end{lstlisting}
-The left-hand side is a tuple of \emph{lvalues}, and the right-hand side is a tuple of \emph{expr}s.
-Each \emph{expr} appearing on the righthand side of a multiple assignment statement is assigned to the corresponding \emph{lvalues} on the left-hand side of the statement using parallel semantics for each assignment.
+[ @\emph{lvalue}@, . . ., @\emph{lvalue}@ ] = [ @\emph{expr}@, . . ., @\emph{expr}@ ];
+\end{lstlisting}
+The left-hand side is a tuple of \lstinline@$\emph{lvalues}$@, and the right-hand side is a tuple of \lstinline@$\emph{expr}$@s.
+Each \lstinline@$\emph{expr}$@ appearing on the righthand side of a multiple assignment statement is assigned to the corresponding \lstinline@$\emph{lvalues}$@ on the left-hand side of the statement using parallel semantics for each assignment.
 An example of multiple assignment is:
 \begin{lstlisting}
 [ x, y, z ] = [ 1, 2, 3 ];
 \end{lstlisting}
-Here, the values ©1©, ©2© and ©3© are assigned, respectively, to the variables ©x©, ©y© and ©z©.
+Here, the values \lstinline@1@, \lstinline@2@ and \lstinline@3@ are assigned, respectively, to the variables \lstinline@x@, \lstinline@y@ and \lstinline@z@.
  A more complex example is:
 \begin{lstlisting}
 [ i, y[ i ], z ] = [ 1, i, a + b ];
 \end{lstlisting}
-Here, the values ©1©, ©i© and ©a + b© are assigned to the variables ©i©, ©y[i]© and ©z©, respectively.
+Here, the values \lstinline@1@, \lstinline@i@ and \lstinline@a + b@ are assigned to the variables \lstinline@i@, \lstinline@y[i]@ and \lstinline@z@, respectively.
  Note, the parallel semantics of
 multiple assignment ensures:
@@ -1096 +1105 @@
 [ x, y ] = [ y, x ];
 \end{lstlisting}
-correctly interchanges (swaps) the values stored in ©x© and ©y©.
+correctly interchanges (swaps) the values stored in \lstinline@x@ and \lstinline@y@.
 The following cases are errors:
 \begin{lstlisting}
@@ -1117 +1126 @@
 Cascade assignment has the following form:
 \begin{lstlisting}
-§\emph{tuple}§ = §\emph{tuple}§ = ... = §\emph{tuple}§;
+@\emph{tuple}@ = @\emph{tuple}@ = ... = @\emph{tuple}@;
 \end{lstlisting}
 and it has the same parallel semantics as for mass and multiple assignment.
@@ -1135 +1144 @@
 Its general form is:
 \begin{lstlisting}
-§\emph{expr}§ . [ §\emph{fieldlist}§ ]
-§\emph{expr}§ -> [ §\emph{fieldlist}§ ]
-\end{lstlisting}
-\emph{expr} is any expression yielding a value of type record, e.g., ©struct©, ©union©.
-Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}.
+@\emph{expr}@ . [ @\emph{fieldlist}@ ]
+@\emph{expr}@ -> [ @\emph{fieldlist}@ ]
+\end{lstlisting}
+\lstinline@$\emph{expr}$@ is any expression yielding a value of type record, e.g., \lstinline@struct@, \lstinline@union@.
+Each element of \lstinline@$\emph{ fieldlist}$@ is an element of the record specified by \lstinline@$\emph{expr}$@.
 A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is
 the following:
@@ -1154 +1163 @@
 also, it is unnecessary to specify all the fields of a struct in a multiple record-field tuple.
 
-If a field of a ©struct© is itself another ©struct©, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example:
+If a field of a \lstinline@struct@ is itself another \lstinline@struct@, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example:
 \begin{lstlisting}
 struct inner {
@@ -1171 +1180 @@
 \section{Labelled Break/Continue}
 
-While C provides ©break© and ©continue© 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 ©goto© to achieve the equivalent for more than one level of nesting.
-To prevent having to make this switch, the ©break© and ©continue© are extended with a target label to support static multi-level exit~\cite{Buhr85,Java}.
-For the labelled ©break©, it is possible to specify which control structure is the target for exit, as in:
+While C provides \lstinline@break@ and \lstinline@continue@ 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 \lstinline@goto@ to achieve the equivalent for more than one level of nesting.
+To prevent having to make this switch, the \lstinline@break@ and \lstinline@continue@ are extended with a target label to support static multi-level exit~\cite{Buhr85,Java}.
+For the labelled \lstinline@break@, it is possible to specify which control structure is the target for exit, as in:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{lstlisting}
-®L1:® for ( ... ) {
-        ®L2:® for ( ... ) {
-                ®L3:® for ( ... ) {
-                        ... break ®L1®; ...
-                        ... break ®L2®; ...
-                        ... break ®L3®; // or break
+`L1:` for ( ... ) {
+        `L2:` for ( ... ) {
+                `L3:` for ( ... ) {
+                        ... break `L1`; ...
+                        ... break `L2`; ...
+                        ... break `L3`; // or break
                 }
         }
@@ -1204 +1213 @@
 \end{quote2}
 The inner most loop has three exit points, which cause termination of one or more of the three nested loops, respectively.
-For the labelled ©continue©, it is possible to specify which control structure is the target for the next loop iteration, as in:
+For the labelled \lstinline@continue@, it is possible to specify which control structure is the target for the next loop iteration, as in:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{lstlisting}
-®L1®: for ( ... ) {
-        ®L2®: for ( ... ) {
-                ®L3®: for ( ... ) {
-                        ... continue ®L1®; ...
-                        ... continue ®L2®; ...
-                        ... continue ®L3®; ...
+`L1`: for ( ... ) {
+        `L2`: for ( ... ) {
+                `L3`: for ( ... ) {
+                        ... continue `L1`; ...
+                        ... continue `L2`; ...
+                        ... continue `L3`; ...
 
                 }
@@ -1240 +1249 @@
 \end{quote2}
 The inner most loop has three restart points, which cause the next loop iteration to begin, respectively.
-For both ©break© and ©continue©, 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© statement.
-Both ©break© and ©continue© with target labels are simply a ©goto© restricted in the following ways:
+For both \lstinline@break@ and \lstinline@continue@, the target label must be directly associated with a \lstinline@for@, \lstinline@while@ or \lstinline@do@ statement;
+for \lstinline@break@, the target label can also be associated with a \lstinline@switch@ statement.
+Both \lstinline@break@ and \lstinline@continue@ with target labels are simply a \lstinline@goto@ restricted in the following ways:
 \begin{itemize}
 \item
@@ -1251 +1260 @@
 Since they always transfers out of containing control structures, they cannot be used to branch into a control structure.
 \end{itemize}
-The advantage of the labelled ©break©/©continue© is that it allows static multi-level exits without having to use the ©goto© statement and ties control flow to the target control structure rather than an arbitrary point in a program.
+The advantage of the labelled \lstinline@break@/\lstinline@continue@ is that it allows static multi-level exits without having to use the \lstinline@goto@ statement and ties control flow to the target control structure rather than an arbitrary point in a program.
 Furthermore, the location of the label at the beginning of the target control structure informs the reader that complex control-flow is occurring in the body of the control structure.
-With ©goto©, the label at the end of the control structure fails to convey this important clue early enough to the reader.
+With \lstinline@goto@, the label at the end of the control structure fails to convey this important clue early enough to the reader.
 Finally, using an explicit target for the transfer instead of an implicit target allows new nested loop or switch constructs to be added or removed without affecting other constructs.
-The implicit targets of the current ©break© and ©continue©, i.e., the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
+The implicit targets of the current \lstinline@break@ and \lstinline@continue@, i.e., the closest enclosing loop or \lstinline@switch@, change as certain constructs are added or removed.
 
 
 \section{Switch Statement}
 
-C allows a number of questionable forms for the ©switch© statement:
+C allows a number of questionable forms for the \lstinline@switch@ statement:
 \begin{enumerate}
 \item
-By default, the end of a ©case© clause\footnote{
-In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
-\emph{falls through} to the next ©case© clause in the ©switch© statement;
-to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©, as in:
+By default, the end of a \lstinline@case@ clause\footnote{
+In this section, the term \emph{case clause} refers to either a \lstinline@case@ or \lstinline@default@ clause.}
+\emph{falls through} to the next \lstinline@case@ clause in the \lstinline@switch@ statement;
+to exit a \lstinline@switch@ statement from a \lstinline@case@ clause requires explicitly terminating the clause with a transfer statement, most commonly \lstinline@break@, as in:
 \begin{lstlisting}
 switch ( i ) {
@@ -1291 +1300 @@
 \end{lstlisting}
 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 \lstinline@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, as in:
 \begin{lstlisting}
@@ -1304 +1313 @@
 \end{lstlisting}
 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 not intuitive to most programmers and is different from virtually all other programming languages with a ©switch© statement.
-Hence, ©default© fall-through semantics results in a large number of programming errors as programmers often forget the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
-
-\item
-It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement, as in:
+While fall-through itself is not a problem, the problem occurs when fall-through is the \lstinline@default@, as this semantics is not intuitive to most programmers and is different from virtually all other programming languages with a \lstinline@switch@ statement.
+Hence, \lstinline@default@ fall-through semantics results in a large number of programming errors as programmers often forget the \lstinline@break@ statement at the end of a \lstinline@case@ clause, resulting in inadvertent fall-through.
+
+\item
+It is possible to place \lstinline@case@ clauses on statements nested \emph{within} the body of the \lstinline@switch@ statement, as in:
 \begin{lstlisting}
 switch ( i ) {
@@ -1349 +1358 @@
 }
 \end{lstlisting}
-which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
+which unrolls a loop N times (N = 8 above) and uses the \lstinline@switch@ statement to deal with any iterations not a multiple of N.
 While efficient, this sort of special purpose usage is questionable:
 \begin{quote}
@@ -1356 +1365 @@
 \end{quote}
 \item
-It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
-Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
-The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
-hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
-This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
-
-\item
-It is possible to place unreachable code at the start of a ©switch© statement, as in:
+It is possible to place the \lstinline@default@ clause anywhere in the list of labelled clauses for a \lstinline@switch@ statement, rather than only at the end.
+Virtually all programming languages with a \lstinline@switch@ statement require the \lstinline@default@ clause to appear last in the case-clause list.
+The logic for this semantics is that after checking all the \lstinline@case@ clauses without success, the \lstinline@default@ clause is selected;
+hence, physically placing the \lstinline@default@ clause at the end of the \lstinline@case@ clause list matches with this semantics.
+This physical placement can be compared to the physical placement of an \lstinline@else@ clause at the end of a series of connected \lstinline@if@/\lstinline@else@ statements.
+
+\item
+It is possible to place unreachable code at the start of a \lstinline@switch@ statement, as in:
 \begin{lstlisting}
 switch ( x ) {
@@ -1373 +1382 @@
 }
 \end{lstlisting}
-While the declaration of the local variable ©y© is useful and its scope is 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 transfered to using a ©goto©, either from outside or inside of the ©switch©.
+While the declaration of the local variable \lstinline@y@ is useful and its scope is across all \lstinline@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 \lstinline@case@ clause can only be executed if labelled and transfered to using a \lstinline@goto@, either from outside or inside of the \lstinline@switch@.
 As mentioned, transfer into control structures should be forbidden.
-Transfers from within the ©switch© body using a ©goto© are equally unpalatable.
+Transfers from within the \lstinline@switch@ body using a \lstinline@goto@ are equally unpalatable.
 \end{enumerate}
 Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
 \begin{itemize}
 \item
-the number of ©switch© statements is small,
-\item
-most ©switch© statements are well formed (i.e., no Duff's device),
-\item
-the ©default© clause is usually written as the last case-clause,
-\item
-and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
+the number of \lstinline@switch@ statements is small,
+\item
+most \lstinline@switch@ statements are well formed (i.e., no Duff's device),
+\item
+the \lstinline@default@ clause is usually written as the last case-clause,
+\item
+and there is only a medium amount of fall-through from one \lstinline@case@ clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
 \end{itemize}
 These observations should help to put the effects of suggested changes into perspective.
@@ -1393 +1402 @@
 \begin{enumerate}
 \item
-Eliminating the ©default© fall-through problem has the greatest potential for affecting existing code.
-However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, and the common placement of the ©default© clause at the end of the case list.
-In addition, the above grammar provides for the most common use of fall-through, i.e., a list of ©case© clauses executing common code, e.g.:
+Eliminating the \lstinline@default@ fall-through problem has the greatest potential for affecting existing code.
+However, even if fall-through is removed, most \lstinline@switch@ statements would continue to work because of the explicit transfers already present at the end of each \lstinline@case@ clause, and the common placement of the \lstinline@default@ clause at the end of the case list.
+In addition, the above grammar provides for the most common use of fall-through, i.e., a list of \lstinline@case@ clauses executing common code, e.g.:
 \begin{lstlisting}
 case 1:  case 2:  case 3: ...
 \end{lstlisting}
 Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
-Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no fall-through semantics.
-The ©choose© statement is identical to the new ©switch© statement, except there is no implicit fall-through between case-clauses and the ©break© statement applies to the enclosing loop construct (as for the continue statement in a ©switch© statement).
+Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of \lstinline@switch@ statement, called \lstinline@choose@, with no fall-through semantics.
+The \lstinline@choose@ statement is identical to the new \lstinline@switch@ statement, except there is no implicit fall-through between case-clauses and the \lstinline@break@ statement applies to the enclosing loop construct (as for the continue statement in a \lstinline@switch@ statement).
 It is still possible to fall-through if a case-clause ends with the new keyword fallthru, e.g.:
 \begin{lstlisting}
@@ -1417 +1426 @@
 \item
 Eliminating Duff's device is straightforward and only invalidates a small amount of very questionable code.
-The solution is to allow ©case© clauses to only appear at the same nesting level as the ©switch© body, as is done in most other programming languages with ©switch© statements.
-\item
-The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause may appear is locations other than at the end.
+The solution is to allow \lstinline@case@ clauses to only appear at the same nesting level as the \lstinline@switch@ body, as is done in most other programming languages with \lstinline@switch@ statements.
+\item
+The issue of \lstinline@default@ at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the \lstinline@default@ clause may appear is locations other than at the end.
 Therefore, no language change is made for this issue.
 \item
-Dealing with unreachable code at the start of a ©switch© statement is solved by defining the declaration-list, including any associated initialization, at the start of a ©switch© statement body to be executed before the transfer to the appropriate ©case© clause.
+Dealing with unreachable code at the start of a \lstinline@switch@ statement is solved by defining the declaration-list, including any associated initialization, at the start of a \lstinline@switch@ statement body to be executed before the transfer to the appropriate \lstinline@case@ clause.
 This semantics is the same as for declarations at the start of a loop body, which are executed before each iteration of the loop body.
-As well, this grammar does not allow statements to appear before the first ©case© clause.
+As well, this grammar does not allow statements to appear before the first \lstinline@case@ clause.
 The change is compatible for declarations with initialization in this context because existing code cannot assume the initialization has occurred.
 The change is incompatible for statements, but any existing code using it is highly questionable, as in:
@@ -1434 +1443 @@
 }
 \end{lstlisting}
-The statement after the ©switch© can never be executed unless it is labelled.
-If it is labelled, it must be transfered to from outside or inside the ©switch© statement, neither of which is acceptable control flow.
+The statement after the \lstinline@switch@ can never be executed unless it is labelled.
+If it is labelled, it must be transfered to from outside or inside the \lstinline@switch@ statement, neither of which is acceptable control flow.
 \end{enumerate}
 
@@ -1441 +1450 @@
 \section{Case Clause}
 
-C restricts the ©case© clause of a ©switch© statement to a single value.
-For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
-Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
-Therefore, the ©case© clause is extended with a list of values, as in:
+C restricts the \lstinline@case@ clause of a \lstinline@switch@ statement to a single value.
+For multiple \lstinline@case@ clauses associated with the same statement, it is necessary to have multiple \lstinline@case@ clauses rather than multiple values.
+Requiring a \lstinline@case@ clause for each value does not seem to be in the spirit of brevity normally associated with C.
+Therefore, the \lstinline@case@ clause is extended with a list of values, as in:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
@@ -1450 +1459 @@
 \begin{lstlisting}
 switch ( i ) {
-  ®case 1, 3, 5®:
+  `case 1, 3, 5`:
         ...
-  ®case 2, 4, 6®:
+  `case 2, 4, 6`:
         ...
 }
@@ -1482 +1491 @@
 \begin{lstlisting}
 switch ( i ) {
-  ®case 1~5:®
+  `case 1~5:`
         ...
-  ®case 10~15:®
+  `case 10~15:`
         ...
 }
@@ -1739 +1748 @@
 
 The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.
-Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
+Use \lstinline@&@ to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
 When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
-The ©&© is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.
+The \lstinline@&@ is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.
 
 \begin{figure}
@@ -1814 +1823 @@
 In \CFA, as in C, all scalar types can be incremented and
 decremented, which is defined in terms of adding or subtracting 1.
-The operations ©&&©, ©||©, and ©!© can be applied to any scalar arguments and are defined in terms of comparison against 0 (ex. ©(a && b)© becomes ©(a != 0 && b != 0)©).
+The operations \lstinline@&&@, \lstinline@||@, and \lstinline@!@ can be applied to any scalar arguments and are defined in terms of comparison against 0 (ex. \lstinline@(a && b)@ becomes \lstinline@(a != 0 && b != 0)@).
 
 In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any
@@ -1823 +1832 @@
 polymorphic parameters, and user-defined pointer-like types may need a null value.
 Defining special
-constants for a user-defined type is more efficient than defining a conversion to the type from ©_Bool©.
+constants for a user-defined type is more efficient than defining a conversion to the type from \lstinline@_Bool@.
 
 Why just 0 and 1? Why not other integers? No other integers have special status in C.
@@ -1906 +1915 @@
 \begin{tabular}[t]{ll}
 %identifier & operation \\ \hline
-©?[?]© & subscripting \impl{?[?]}\\
-©?()© & function call \impl{?()}\\
-©?++© & postfix increment \impl{?++}\\
-©?--© & postfix decrement \impl{?--}\\
-©++?© & prefix increment \impl{++?}\\
-©--?© & prefix decrement \impl{--?}\\
-©*?© & dereference \impl{*?}\\
-©+?© & unary plus \impl{+?}\\
-©-?© & arithmetic negation \impl{-?}\\
-©~?© & bitwise negation \impl{~?}\\
-©!?© & logical complement \impl{"!?}\\
-©?*?© & multiplication \impl{?*?}\\
-©?/?© & division \impl{?/?}\\
+\lstinline@?[?]@ & subscripting \impl{?[?]}\\
+\lstinline@?()@ & function call \impl{?()}\\
+\lstinline@?++@ & postfix increment \impl{?++}\\
+\lstinline@?--@ & postfix decrement \impl{?--}\\
+\lstinline@++?@ & prefix increment \impl{++?}\\
+\lstinline@--?@ & prefix decrement \impl{--?}\\
+\lstinline@*?@ & dereference \impl{*?}\\
+\lstinline@+?@ & unary plus \impl{+?}\\
+\lstinline@-?@ & arithmetic negation \impl{-?}\\
+\lstinline@~?@ & bitwise negation \impl{~?}\\
+\lstinline@!?@ & logical complement \impl{"!?}\\
+\lstinline@?*?@ & multiplication \impl{?*?}\\
+\lstinline@?/?@ & division \impl{?/?}\\
 \end{tabular}\hfil
 \begin{tabular}[t]{ll}
 %identifier & operation \\ \hline
-©?%?© & remainder \impl{?%?}\\
-©?+?© & addition \impl{?+?}\\
-©?-?© & subtraction \impl{?-?}\\
-©?<<?© & left shift \impl{?<<?}\\
-©?>>?© & right shift \impl{?>>?}\\
-©?<?© & less than \impl{?<?}\\
-©?<=?© & less than or equal \impl{?<=?}\\
-©?>=?© & greater than or equal \impl{?>=?}\\
-©?>?© & greater than \impl{?>?}\\
-©?==?© & equality \impl{?==?}\\
-©?!=?© & inequality \impl{?"!=?}\\
-©?&?© & bitwise AND \impl{?&?}\\
+\lstinline@?%?@ & remainder \impl{?%?}\\
+\lstinline@?+?@ & addition \impl{?+?}\\
+\lstinline@?-?@ & subtraction \impl{?-?}\\
+\lstinline@?<<?@ & left shift \impl{?<<?}\\
+\lstinline@?>>?@ & right shift \impl{?>>?}\\
+\lstinline@?<?@ & less than \impl{?<?}\\
+\lstinline@?<=?@ & less than or equal \impl{?<=?}\\
+\lstinline@?>=?@ & greater than or equal \impl{?>=?}\\
+\lstinline@?>?@ & greater than \impl{?>?}\\
+\lstinline@?==?@ & equality \impl{?==?}\\
+\lstinline@?!=?@ & inequality \impl{?"!=?}\\
+\lstinline@?&?@ & bitwise AND \impl{?&?}\\
 \end{tabular}\hfil
 \begin{tabular}[t]{ll}
 %identifier & operation \\ \hline
-©?^?© & exclusive OR \impl{?^?}\\
-©?|?© & inclusive OR \impl{?"|?}\\
-©?=?© & simple assignment \impl{?=?}\\
-©?*=?© & multiplication assignment \impl{?*=?}\\
-©?/=?© & division assignment \impl{?/=?}\\
-©?%=?© & remainder assignment \impl{?%=?}\\
-©?+=?© & addition assignment \impl{?+=?}\\
-©?-=?© & subtraction assignment \impl{?-=?}\\
-©?<<=?© & left-shift assignment \impl{?<<=?}\\
-©?>>=?© & right-shift assignment \impl{?>>=?}\\
-©?&=?© & bitwise AND assignment \impl{?&=?}\\
-©?^=?© & exclusive OR assignment \impl{?^=?}\\
-©?|=?© & inclusive OR assignment \impl{?"|=?}\\
+\lstinline@?^?@ & exclusive OR \impl{?^?}\\
+\lstinline@?|?@ & inclusive OR \impl{?"|?}\\
+\lstinline@?=?@ & simple assignment \impl{?=?}\\
+\lstinline@?*=?@ & multiplication assignment \impl{?*=?}\\
+\lstinline@?/=?@ & division assignment \impl{?/=?}\\
+\lstinline@?%=?@ & remainder assignment \impl{?%=?}\\
+\lstinline@?+=?@ & addition assignment \impl{?+=?}\\
+\lstinline@?-=?@ & subtraction assignment \impl{?-=?}\\
+\lstinline@?<<=?@ & left-shift assignment \impl{?<<=?}\\
+\lstinline@?>>=?@ & right-shift assignment \impl{?>>=?}\\
+\lstinline@?&=?@ & bitwise AND assignment \impl{?&=?}\\
+\lstinline@?^=?@ & exclusive OR assignment \impl{?^=?}\\
+\lstinline@?|=?@ & inclusive OR assignment \impl{?"|=?}\\
 \end{tabular}
 \hfil
@@ -1958 +1967 @@
 These identifiers are defined such that the question marks in the name identify the location of the operands.
 These operands represent the parameters to the functions, and define how the operands are mapped to the function call.
-For example, ©a + b© becomes ©?+?(a, b)©.
+For example, \lstinline@a + b@ becomes \lstinline@?+?(a, b)@.
 
 In the example below, a new type, myComplex, is defined with an overloaded constructor, + operator, and string operator.
@@ -2001 +2010 @@
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}ll@{}}
-\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CC}}        & \multicolumn{1}{c}{©gcc©}\index{gcc} \\
+\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CC}}        & \multicolumn{1}{c}{\lstinline@gcc@}\index{gcc} \\
 \begin{lstlisting}
 
@@ -2032 +2041 @@
 \end{itemize}
 
-In \CFA, ©typedef© provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
-©gcc© provides ©typeof© to declare a secondary variable from a primary variable.
+In \CFA, \lstinline@typedef@ provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
+\lstinline@gcc@ provides \lstinline@typeof@ to declare a secondary variable from a primary variable.
 \CFA also relies heavily on the specification of the left-hand side of assignment for type inferencing, so in many cases it is crucial to specify the type of the left-hand side to select the correct type of the right-hand expression.
 Only for overloaded routines with the same return type is variable type-inferencing possible.
-Finally, ©auto© presents the programming problem of tracking down a type when the type is actually needed.
+Finally, \lstinline@auto@ presents the programming problem of tracking down a type when the type is actually needed.
 For example, given
 \begin{lstlisting}
-auto j = ®...®
-\end{lstlisting}
-and the need to write a routine to compute using ©j©
-\begin{lstlisting}
-void rtn( ®...® parm );
+auto j = `...`
+\end{lstlisting}
+and the need to write a routine to compute using \lstinline@j@
+\begin{lstlisting}
+void rtn( `...` parm );
 rtn( j );
 \end{lstlisting}
-A programmer must work backwards to determine the type of ©j©'s initialization expression, reconstructing the possibly long generic type-name.
+A programmer must work backwards to determine the type of \lstinline@j@'s initialization expression, reconstructing the possibly long generic type-name.
 In this situation, having the type name or a short alias is very useful.
 
@@ -2054 +2063 @@
 At some point, a programmer wants the type of the variable to remain constant and the expression to be in error when it changes.
 
-Given ©typedef© and ©typeof© in \CFA, and the strong need to use the type of left-hand side in inferencing, auto type-inferencing is not supported at this time.
+Given \lstinline@typedef@ and \lstinline@typeof@ in \CFA, and the strong need to use the type of left-hand side in inferencing, auto type-inferencing is not supported at this time.
 Should a significant need arise, this feature can be revisited.
 
@@ -2356 +2365 @@
 } s;
 \end{lstlisting}
-The problem occurs in accesing these fields using the selection operation ``©.©'':
+The problem occurs in accesing these fields using the selection operation ``\lstinline@.@'':
 \begin{lstlisting}
 s.0 = 0;        // ambiguity with floating constant .0
@@ -2363 +2372 @@
 To make this work, a space is required after the field selection:
 \begin{lstlisting}
-®s.§\textvisiblespace§0® = 0;
-®s.§\textvisiblespace§1® = 1;
+`s.@\textvisiblespace@0` = 0;
+`s.@\textvisiblespace@1` = 1;
 \end{lstlisting}
 While this sytact is awkward, it is unlikely many programers will name fields of a structure 0 or 1.
-Like the \CC lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser.
-
-There are several ambiguous cases with operator identifiers, e.g., ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©.
-Since it is common practise to put a unary operator juxtaposed to an identifier, e.g., ©*i©, users will be annoyed if they cannot do this with respect to operator identifiers.
+Like the \CC lexical problem with closing template-syntax, e.g, \lstinline@Foo<Bar<int`>>`@, this issue can be solved with a more powerful lexer/parser.
+
+There are several ambiguous cases with operator identifiers, e.g., \lstinline@int *?*?()@, where the string \lstinline@*?*?@ can be lexed as \lstinline@*@/\lstinline@?*?@ or \lstinline@*?@/\lstinline@*?@.
+Since it is common practise to put a unary operator juxtaposed to an identifier, e.g., \lstinline@*i@, users will be annoyed if they cannot do this with respect to operator identifiers.
 Even with this special hack, there are 5 general cases that cannot be handled.
-The first case is for the function-call identifier ©?()©:
-\begin{lstlisting}
-int *§\textvisiblespace§?()();  // declaration: space required after '*'
-*§\textvisiblespace§?()();              // expression: space required after '*'
-\end{lstlisting}
-Without the space, the string ©*?()© is ambiguous without N character look ahead;
-it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list.
+The first case is for the function-call identifier \lstinline@?()@:
+\begin{lstlisting}
+int *@\textvisiblespace@?()();  // declaration: space required after '*'
+*@\textvisiblespace@?()();              // expression: space required after '*'
+\end{lstlisting}
+Without the space, the string \lstinline@*?()@ is ambiguous without N character look ahead;
+it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument/parameter list.
 
 The 4 remaining cases occur in expressions:
 \begin{lstlisting}
-i++§\textvisiblespace§?i:0;             // space required before '?'
-i--§\textvisiblespace§?i:0;             // space required before '?'
-i§\textvisiblespace§?++i:0;             // space required after '?'
-i§\textvisiblespace§?--i:0;             // space required after '?'
-\end{lstlisting}
-In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©;
-it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
-In the second two cases, the string ©?++x© is ambiguous, where this string can be lexed as ©?++© / ©x© or ©?© / y©++x©;
-it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
+i++@\textvisiblespace@?i:0;             // space required before '?'
+i--@\textvisiblespace@?i:0;             // space required before '?'
+i@\textvisiblespace@?++i:0;             // space required after '?'
+i@\textvisiblespace@?--i:0;             // space required after '?'
+\end{lstlisting}
+In the first two cases, the string \lstinline@i++?@ is ambiguous, where this string can be lexed as \lstinline@i@ / \lstinline@++?@ or \lstinline@i++@ / \lstinline@?@;
+it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument list.
+In the second two cases, the string \lstinline@?++x@ is ambiguous, where this string can be lexed as \lstinline@?++@ / \lstinline@x@ or \lstinline@?@ / y\lstinline@++x@;
+it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument list.
 
 
@@ -3316 +3325 @@
 
 
-\subsection[Comparing Key Features of CFA]{Comparing Key Features of \CFA}
+\subsection{Comparing Key Features of \CFA}
 
 
@@ -3690 +3699 @@
 
 \begin{comment}
-\subsubsection{Modules / Packages}
+\subsubsection{Modules/Packages}
 
 \begin{lstlisting}
@@ -3932 +3941 @@
 
 
-\subsubsection[C++]{\CC}
+\subsubsection{\CC}
 
 \CC is a general-purpose programming language.
@@ -4006 +4015 @@
 \begin{enumerate}
 \item
-Change type of character literal ©int© to ©char©.
+Change type of character literal \lstinline@int@ to \lstinline@char@.
 This change allows overloading differentiation argument type matching, e.g.:
 \begin{lstlisting}
@@ -4023 +4032 @@
 
 \item
-Change: String literals made ©const© \\
-The type of a string literal is changed from ©array of char© to ©array of const char©.
-The type of a wide string literal is changed from ©array of wchar_t© to ©array of const wchar_t©. \\
+Change: String literals made \lstinline@const@ \\
+The type of a string literal is changed from \lstinline@array of char@ to \lstinline@array of const char@.
+The type of a wide string literal is changed from \lstinline@array of wchar_t@ to \lstinline@array of const wchar_t@. \\
 Rationale: This avoids calling an inappropriate overloaded function, which might expect to be able to modify its argument.
 Effect on original feature: Change to semantics of well-defined feature. \\
-Difficulty of converting: Simple syntactic transformation, because string literals can be converted to ©char*;© (4.2).
+Difficulty of converting: Simple syntactic transformation, because string literals can be converted to \lstinline@char*;@ (4.2).
 The most common cases are handled by a new but deprecated standard conversion:
 \begin{lstlisting}
@@ -4067 +4076 @@
 
 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC.
-Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
+Nested types are not hoisted and can be referenced using the field selection operator ``\lstinline@.@'', unlike the \CC scope-resolution operator ``\lstinline@::@''.
 Given that nested types in C are equivalent to not using them, i.e., they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.
+
 
 \item
@@ -4080 +4090 @@
 struct Y yy; // valid C, invalid C++
 \end{lstlisting}
-Rationale: C++ classes have member functions which require that classes establish scopes.
-The C rule would leave classes as an incomplete scope mechanism which would prevent C++ programmers from maintaining locality within a class. A coherent set of scope rules for C++ based on the C rule would be very complicated and C++ programmers would be unable to predict reliably the meanings of nontrivial examples involving nested or local functions.
-Effect on original feature: Change of semantics of welldefined feature.
-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:
+Rationale: C++ classes have member functions which require that classes establish scopes. The C rule
+would leave classes as an incomplete scope mechanism which would prevent C++ programmers from maintaining
+locality within a class. A coherent set of scope rules for C++ based on the C rule would be very
+complicated and C++ programmers would be unable to predict reliably the meanings of nontrivial examples
+involving nested or local functions.
+Effect on original feature: Change of semantics of welldefined
+feature.
+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{lstlisting}
 struct Y; // struct Y and struct X are at the same scope
@@ -4090 +4106 @@
 };
 \end{lstlisting}
-All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct.
-Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
+All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of
+the enclosing struct could be exported to the scope of the enclosing struct. Note: this is a consequence of
+the difference in scope rules, which is documented in 3.3.
 How widely used: Seldom.
 \end{enumerate}
@@ -4107 +4124 @@
 \begin{lstlisting}
 int x = 0, y = 1, z = 2;
-®sout® ®|® x ®|® y ®|® z ®| endl®;
+`sout` `|` x `|` y `|` z `| endl`;
 \end{lstlisting}
 &
@@ -4116 +4133 @@
 \end{tabular}
 \end{quote2}
-The \CFA form is half as many characters, and is similar to \Index{Python} I/O with respect to implicit separators.
+The \CFA form is half as many characters, and is similar to Python I/O with respect to implicit separators.
 
 The logical-or operator is used because it is the lowest-priority overloadable operator, other than assignment.
@@ -4143 +4160 @@
 A seperator does not appear at the start or end of a line.
 \begin{lstlisting}[belowskip=0pt]
-sout | 1 | 2 | 3 | endl;
+sout 1 | 2 | 3 | endl;
 \end{lstlisting}
 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -4162 +4179 @@
 which is a local mechanism to disable insertion of the separator character.
 \item
-A seperator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{$£¥¡¿«@
+A seperator does not appear before a C string starting with the \Index{extended ASCII}\index{ASCII} characters: \lstinline[mathescape=off]@([{$£¥¿«@
 %$
 \begin{lstlisting}[mathescape=off]
-sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x $" | 4 | "x £" | 5 | "x ¥" | 6 | "x ¡" | 7 | "x ¿" | 8 | "x «" | 9 | endl;
+sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x $" | 4 | "x £" | 5 | "x ¥" | 6 | "x ¿" | 7 | "x «" | 8 | endl;
 \end{lstlisting}
 %$
 \begin{lstlisting}[mathescape=off,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 (1 x [2 x {3 x $4 x £5 x ¥6 x ¿7 x «8
 \end{lstlisting}
 %$
 \item
-A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.:;!?)]}%¢»©
+A seperator does not appear after a C string ending with the extended ASCII characters: \lstinline@,.:;!?)]}%¢»@
 \begin{lstlisting}[belowskip=0pt]
 sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | ") x" | 8 | "] x" | 9 | "} x"
-         | 10 | "% x" | 11 | "¢ x" | 12 | "» x" | endl;
+         | 10 | "% x" | 11 | L"¢ x" | 12 | L"» x" | endl;
 \end{lstlisting}
 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
@@ -4182 +4199 @@
 \end{lstlisting}
 \item
-A seperator does not appear before or after a C string begining/ending with the \Index{ASCII} quote or whitespace characters: \lstinline[showspaces=true]@`'" \t\v\f\r\n@
+A seperator does not appear before or after a C string begining/ending with the characters: \lstinline@\f\n\r\t\v\`'"@
 \begin{lstlisting}[belowskip=0pt]
-sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x" | "x " | 4 | " x" | "x\t" | 1 | "\tx" | endl;
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
-x`1`x'2'x"3"x x 4 x x   1       x
+sout | "x '" | 1 | "' x \`" | 2 | "\` x \"" | 3 | "\" x" | endl;
+\end{lstlisting}
+\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+x '1' x \`2\` x "3" x
+\end{lstlisting}
+\begin{lstlisting}[showtabs=true,aboveskip=0pt]
+sout | "x\t" | 1 | "\tx" | endl;
+x       1       x
 \end{lstlisting}
 \end{enumerate}
@@ -4219 +4240 @@
 \end{lstlisting}
 \begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
- 1 2 3
+1 2 3
 \end{lstlisting}
 \begin{lstlisting}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
@@ -4230 +4251 @@
 \end{lstlisting}
 %$
-\begin{comment}
+\VRef[Figure]{f:ExampleIO} shows an example of input and output I/O in \CFA.
+
+\begin{figure}
+\begin{lstlisting}[mathescape=off]
 #include <fstream>
 
 int main() {
-        int x = 3, y = 5, z = 7;
-        sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
-        sout | 1 | 2 | 3 | endl;
-        sout | '1' | '2' | '3' | endl;
-        sout | 1 | "" | 2 | "" | 3 | endl;
-        sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x $" | 4 | "x £" | 5 | "x ¥" | 6 | "x ¡" | 7 | "x ¿" | 8 | "x «" | 9 | endl;
-        sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | ") x" | 8 | "] x" | 9 | "} x"
-                 | 10 | "% x" | 11 | "¢ x" | 12 | "» x" | endl;
-        sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x" | "x " | 4 | " x" | "x\t" | 1 | "\tx" | endl;
-        sout | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
-        sout | 1 | sepOff | 2 | 3 | endl;                       // turn off implicit separator temporarily
-        sout | sepDisable | 1 | 2 | 3 | endl;           // turn off implicit separation, affects all subsequent prints
-        sout | 1 | sepOn | 2 | 3 | endl;                        // turn on implicit separator temporarily
-        sout | sepEnable | 1 | 2 | 3 | endl;            // turn on implicit separation, affects all subsequent prints
-        sepSet( sout, ", $" );                                          // change separator from " " to ", $"
-        sout | 1 | 2 | 3 | endl;
-
-}
-
-// Local Variables: //
-// tab-width: 4 //
-// End: //
-\end{comment}
-%$
+        char c;                                                                                                         // basic types
+        short int si;
+        unsigned short int usi;
+        int i;
+        unsigned int ui;
+        long int li;
+        unsigned long int uli;
+        long long int lli;
+        unsigned long long int ulli;
+        float f;
+        double d;
+        long double ld;
+        float _Complex fc;
+        double _Complex dc;
+        long double _Complex ldc;
+        char s1[10], s2[10];
+
+        ifstream in;                                                                                            // create / open file
+        open( &in, "input.data", "r" );
+
+        &in | &c                                                                                                        // character
+                | &si | &usi | &i | &ui | &li | &uli | &lli | &ulli             // integral
+                | &f | &d | &ld                                                                                 // floating point
+                | &fc | &dc | &ldc                                                                              // floating-point complex
+                | cstr( s1 ) | cstr( s2, 10 );                                                  // C string, length unchecked and checked
+
+        sout | c | ' ' | endl                                                                           // character
+                 | si | usi | i | ui | li | uli | lli | ulli | endl             // integral
+                 | f | d | ld | endl                                                                    // floating point
+                 | fc | dc | ldc | endl;                                                                // complex
+        sout | endl;
+        sout | f | "" | d | "" | ld | endl                                                      // floating point without separator
+                 | sepDisable | fc | dc | ldc | sepEnable | endl                // complex without separator
+                 | sepOn | s1 | sepOff | s2 | endl                                              // local separator removal
+                 | s1 | "" | s2 | endl;                                                                 // C string withou separator
+        sout | endl;
+        sepSet( sout, ", $" );                                                                          // change separator, maximum of 15 characters
+        sout | f | d | ld | endl                                                                        // floating point without separator
+                 | fc | dc | ldc | endl                                                                 // complex without separator
+                 | s1 | s2 | endl;
+}
+
+$ cat input.data 
+A 1 2 3 4 5 6 7 8 1.1 1.2 1.3 1.1+2.3 1.1-2.3 1.1-2.3 abc xyz
+$ a.out
+A 
+1 2 3 4 5 6 7 8
+1.1 1.2 1.3
+1.1+2.3i 1.1-2.3i 1.1-2.3i
+
+1.11.21.3
+1.1+2.3i1.1-2.3i1.1-2.3i
+ abcxyz
+abcxyz
+
+1.1, $1.2, $1.3
+1.1+2.3i, $1.1-2.3i, $1.1-2.3i
+abc, $xyz
+\end{lstlisting}
+\caption{Example I/O}
+\label{f:ExampleIO}
+\end{figure}
 
 
@@ -4269 +4331 @@
 
 \begin{lstlisting}
-forall( otype T ) T * malloc( void );§\indexc{malloc}§
+forall( otype T ) T * malloc( void );
 forall( otype T ) T * malloc( char fill );
 forall( otype T ) T * malloc( T * ptr, size_t size );
 forall( otype T ) T * malloc( T * ptr, size_t size, unsigned char fill );
-forall( otype T ) T * calloc( size_t nmemb );§\indexc{calloc}§
-forall( otype T ) T * realloc( T * ptr, size_t size );§\indexc{ato}§
+forall( otype T ) T * calloc( size_t size );
+forall( otype T ) T * realloc( T * ptr, size_t size );
 forall( otype T ) T * realloc( T * ptr, size_t size, unsigned char fill );
 
-forall( otype T ) T * aligned_alloc( size_t alignment );§\indexc{ato}§
+forall( otype T ) T * aligned_alloc( size_t alignment );
 forall( otype T ) T * memalign( size_t alignment );             // deprecated
 forall( otype T ) int posix_memalign( T ** ptr, size_t alignment );
@@ -4286 +4348 @@
 
 
-\subsection{ato / strto}
-
-\begin{lstlisting}
-int ato( const char * ptr );§\indexc{ato}§
+\subsection{ato/strto}
+
+\begin{lstlisting}
+int ato( const char * ptr );
 unsigned int ato( const char * ptr );
 long int ato( const char * ptr );
@@ -4317 +4379 @@
 
 
-\subsection{bsearch / qsort}
+\subsection{bsearch/qsort}
 
 \begin{lstlisting}
 forall( otype T | { int ?<?( T, T ); } )
-T * bsearch( const T key, const T * arr, size_t dimension );§\indexc{bsearch}§
+T * bsearch( const T key, const T * arr, size_t dimension );
 
 forall( otype T | { int ?<?( T, T ); } )
-void qsort( const T * arr, size_t dimension );§\indexc{qsort}§
+void qsort( const T * arr, size_t dimension );
 \end{lstlisting}
 
@@ -4331 +4393 @@
 
 \begin{lstlisting}
-char abs( char );§\indexc{abs}§
-int abs( int );
+char abs( char );
+extern "C" {
+int abs( int );                         // use default C routine for int
+} // extern "C"
 long int abs( long int );
 long long int abs( long long int );
@@ -4338 +4402 @@
 double abs( double );
 long double abs( long double );
-float abs( float _Complex );
-double abs( double _Complex );
-long double abs( long double _Complex );
+float _Complex abs( float _Complex );
+double _Complex abs( double _Complex );
+long double _Complex abs( long double _Complex );
+\end{lstlisting}
+
+
+\subsection{floor/ceil}
+
+\begin{lstlisting}
+float floor( float );
+extern "C" {
+double floor( double );         // use C routine for double
+} // extern "C"
+long double floor( long double );
+
+float ceil( float );
+extern "C" {
+double ceil( double );          // use C routine for double
+} // extern "C"
+long double ceil( long double );
 \end{lstlisting}
 
@@ -4347 +4428 @@
 
 \begin{lstlisting}
-void rand48seed( long int s );§\indexc{rand48seed}§
-char rand48();§\indexc{rand48}§
+void rand48seed( long int s );
+char rand48();
 int rand48();
 unsigned int rand48();
@@ -4361 +4442 @@
 
 
-\subsection{min / max / swap}
+\subsection{min/max/swap}
 
 \begin{lstlisting}
 forall( otype T | { int ?<?( T, T ); } )
-T min( const T t1, const T t2 );§\indexc{min}§
+T min( const T t1, const T t2 );
 
 forall( otype T | { int ?>?( T, T ); } )
-T max( const T t1, const T t2 );§\indexc{max}§
+T max( const T t1, const T t2 );
 
 forall( otype T )
-void swap( T * t1, T * t2 );§\indexc{swap}§
-\end{lstlisting}
-
-
-\section{Math Library}
-\label{s:Math Library}
-
-The goal of the \CFA math-library is to wrap many of the existing C math library-routines that are explicitly polymorphic into implicitly polymorphic versions.
-
-
-\subsection{General}
-
-\begin{lstlisting}
-float fabs( float );§\indexc{fabs}§
-double fabs( double );
-long double fabs( long double );
-float cabs( float _Complex );
-double cabs( double _Complex );
-long double cabs( long double _Complex );
-
-float ?%?( float, float );§\indexc{fmod}§
-float fmod( float, float );
-double ?%?( double, double );
-double fmod( double, double );
-long double ?%?( long double, long double );
-long double fmod( long double, long double );
-
-float remainder( float, float );§\indexc{remainder}§
-double remainder( double, double );
-long double remainder( long double, long double );
-
-[ int, float ] remquo( float, float );§\indexc{remquo}§
-float remquo( float, float, int * );
-[ int, double ] remquo( double, double );
-double remquo( double, double, int * );
-[ int, long double ] remquo( long double, long double );
-long double remquo( long double, long double, int * );
-
-[ int, float ] div( float, float );                                             // alternative name for remquo
-float div( float, float, int * );§\indexc{div}§
-[ int, double ] div( double, double );
-double div( double, double, int * );
-[ int, long double ] div( long double, long double );
-long double div( long double, long double, int * );
-
-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}§
-double fdim( double, double );
-long double fdim( long double, long double );
-
-float nan( const char * );§\indexc{nan}§
-double nan( const char * );
-long double nan( const char * );
-\end{lstlisting}
-
-
-\subsection{Exponential}
-
-\begin{lstlisting}
-float exp( float );§\indexc{exp}§
-double exp( double );
-long double exp( long double );
-float _Complex exp( float _Complex );
-double _Complex exp( double _Complex );
-long double _Complex exp( long double _Complex );
-
-float exp2( float );§\indexc{exp2}§
-double exp2( double );
-long double exp2( long double );
-float _Complex exp2( float _Complex );
-double _Complex exp2( double _Complex );
-long double _Complex exp2( long double _Complex );
-
-float expm1( float );§\indexc{expm1}§
-double expm1( double );
-long double expm1( long double );
-
-float log( float );§\indexc{log}§
-double log( double );
-long double log( long double );
-float _Complex log( float _Complex );
-double _Complex log( double _Complex );
-long double _Complex log( long double _Complex );
-
-float log2( float );§\indexc{log2}§
-double log2( double );
-long double log2( long double );
-float _Complex log2( float _Complex );
-double _Complex log2( double _Complex );
-long double _Complex log2( long double _Complex );
-
-float log10( float );§\indexc{log10}§
-double log10( double );
-long double log10( long double );
-float _Complex log10( float _Complex );
-double _Complex log10( double _Complex );
-long double _Complex log10( long double _Complex );
-
-float log1p( float );§\indexc{log1p}§
-double log1p( double );
-long double log1p( long double );
-
-int ilogb( float );§\indexc{ilogb}§
-int ilogb( double );
-int ilogb( long double );
-
-float logb( float );§\indexc{logb}§
-double logb( double );
-long double logb( long double );
-\end{lstlisting}
-
-
-\subsection{Power}
-
-\begin{lstlisting}
-float sqrt( float );§\indexc{sqrt}§
-double sqrt( double );
-long double sqrt( long double );
-float _Complex sqrt( float _Complex );
-double _Complex sqrt( double _Complex );
-long double _Complex sqrt( long double _Complex );
-
-float cbrt( float );§\indexc{cbrt}§
-double cbrt( double );
-long double cbrt( long double );
-
-float hypot( float, float );§\indexc{hypot}§
-double hypot( double, double );
-long double hypot( long double, long double );
-
-float pow( float, float );§\indexc{pow}§
-double pow( double, double );
-long double pow( long double, long double );
-float _Complex pow( float _Complex, float _Complex );
-double _Complex pow( double _Complex, double _Complex );
-long double _Complex pow( long double _Complex, long double _Complex );
-\end{lstlisting}
-
-
-\subsection{Trigonometric}
-
-\begin{lstlisting}
-float sin( float );§\indexc{sin}§
-double sin( double );
-long double sin( long double );
-float _Complex sin( float _Complex );
-double _Complex sin( double _Complex );
-long double _Complex sin( long double _Complex );
-
-float cos( float );§\indexc{cos}§
-double cos( double );
-long double cos( long double );
-float _Complex cos( float _Complex );
-double _Complex cos( double _Complex );
-long double _Complex cos( long double _Complex );
-
-float tan( float );§\indexc{tan}§
-double tan( double );
-long double tan( long double );
-float _Complex tan( float _Complex );
-double _Complex tan( double _Complex );
-long double _Complex tan( long double _Complex );
-
-float asin( float );§\indexc{asin}§
-double asin( double );
-long double asin( long double );
-float _Complex asin( float _Complex );
-double _Complex asin( double _Complex );
-long double _Complex asin( long double _Complex );
-
-float acos( float );§\indexc{acos}§
-double acos( double );
-long double acos( long double );
-float _Complex acos( float _Complex );
-double _Complex acos( double _Complex );
-long double _Complex acos( long double _Complex );
-
-float atan( float );§\indexc{atan}§
-double atan( double );
-long double atan( long double );
-float _Complex atan( float _Complex );
-double _Complex atan( double _Complex );
-long double _Complex atan( long double _Complex );
-
-float atan2( float, float );§\indexc{atan2}§
-double atan2( double, double );
-long double atan2( long double, long double );
-
-float atan( float, float );                                                             // alternative name for atan2
-double atan( double, double );§\indexc{atan}§
-long double atan( long double, long double );
-\end{lstlisting}
-
-
-\subsection{Hyperbolic}
-
-\begin{lstlisting}
-float sinh( float );§\indexc{sinh}§
-double sinh( double );
-long double sinh( long double );
-float _Complex sinh( float _Complex );
-double _Complex sinh( double _Complex );
-long double _Complex sinh( long double _Complex );
-
-float cosh( float );§\indexc{cosh}§
-double cosh( double );
-long double cosh( long double );
-float _Complex cosh( float _Complex );
-double _Complex cosh( double _Complex );
-long double _Complex cosh( long double _Complex );
-
-float tanh( float );§\indexc{tanh}§
-double tanh( double );
-long double tanh( long double );
-float _Complex tanh( float _Complex );
-double _Complex tanh( double _Complex );
-long double _Complex tanh( long double _Complex );
-
-float asinh( float );§\indexc{asinh}§
-double asinh( double );
-long double asinh( long double );
-float _Complex asinh( float _Complex );
-double _Complex asinh( double _Complex );
-long double _Complex asinh( long double _Complex );
-
-float acosh( float );§\indexc{acosh}§
-double acosh( double );
-long double acosh( long double );
-float _Complex acosh( float _Complex );
-double _Complex acosh( double _Complex );
-long double _Complex acosh( long double _Complex );
-
-float atanh( float );§\indexc{atanh}§
-double atanh( double );
-long double atanh( long double );
-float _Complex atanh( float _Complex );
-double _Complex atanh( double _Complex );
-long double _Complex atanh( long double _Complex );
-\end{lstlisting}
-
-
-\subsection{Error / Gamma}
-
-\begin{lstlisting}
-float erf( float );§\indexc{erf}§
-double erf( double );
-long double erf( long double );
-float _Complex erf( float _Complex );
-double _Complex erf( double _Complex );
-long double _Complex erf( long double _Complex );
-
-float erfc( float );§\indexc{erfc}§
-double erfc( double );
-long double erfc( long double );
-float _Complex erfc( float _Complex );
-double _Complex erfc( double _Complex );
-long double _Complex erfc( long double _Complex );
-
-float lgamma( float );§\indexc{lgamma}§
-double lgamma( double );
-long double lgamma( long double );
-float lgamma( float, int * );
-double lgamma( double, int * );
-long double lgamma( long double, int * );
-
-float tgamma( float );§\indexc{tgamma}§
-double tgamma( double );
-long double tgamma( long double );
-\end{lstlisting}
-
-
-\subsection{Nearest Integer}
-
-\begin{lstlisting}
-float floor( float );§\indexc{floor}§
-double floor( double );
-long double floor( long double );
-
-float ceil( float );§\indexc{ceil}§
-double ceil( double );
-long double ceil( long double );
-
-float trunc( float );§\indexc{trunc}§
-double trunc( double );
-long double trunc( long double );
-
-float rint( float );§\indexc{rint}§
-long double rint( long double );
-long int rint( float );
-long int rint( double );
-long int rint( long double );
-long long int rint( float );
-long long int rint( double );
-long long int rint( long double );
-
-long int lrint( float );§\indexc{lrint}§
-long int lrint( double );
-long int lrint( long double );
-long long int llrint( float );
-long long int llrint( double );
-long long int llrint( long double );
-
-float nearbyint( float );§\indexc{nearbyint}§
-double nearbyint( double );
-long double nearbyint( long double );
-
-float round( float );§\indexc{round}§
-long double round( long double );
-long int round( float );
-long int round( double );
-long int round( long double );
-long long int round( float );
-long long int round( double );
-long long int round( long double );
-
-long int lround( float );§\indexc{lround}§
-long int lround( double );
-long int lround( long double );
-long long int llround( float );
-long long int llround( double );
-long long int llround( long double );
-\end{lstlisting}
-
-
-\subsection{Manipulation}
-
-\begin{lstlisting}
-float copysign( float, float );§\indexc{copysign}§
-double copysign( double, double );
-long double copysign( long double, long double );
-
-float frexp( float, int * );§\indexc{frexp}§
-double frexp( double, int * );
-long double frexp( long double, int * );
-
-float ldexp( float, int );§\indexc{ldexp}§
-double ldexp( double, int );
-long double ldexp( long double, int );
-
-[ float, float ] modf( float );§\indexc{modf}§
-float modf( float, float * );
-[ double, double ] modf( double );
-double modf( double, double * );
-[ long double, long double ] modf( long double );
-long double modf( long double, long double * );
-
-float nextafter( float, float );§\indexc{nextafter}§
-double nextafter( double, double );
-long double nextafter( long double, long double );
-
-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}§
-double scalbn( double, int );
-long double scalbn( long double, int );
-
-float scalbln( float, long int );§\indexc{scalbln}§
-double scalbln( double, long int );
-long double scalbln( long double, long int );
+void swap( T * t1, T * t2 );
 \end{lstlisting}
 
@@ -4746 +4464 @@
 \begin{lstlisting}
 // implementation
-struct Rational {§\indexc{Rational}§
+struct Rational {
         long int numerator, denominator;                                        // invariant: denominator > 0
 }; // Rational