Index: doc/user/user.tex
===================================================================
--- doc/user/user.tex	(revision 0583064b51c8067d17ccf652042bb775c321d751)
+++ doc/user/user.tex	(revision 221c2de713dc5e3785b9b4dbc558dfa20b70714e)
@@ -11,6 +11,6 @@
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
-%% Last Modified On : Thu Mar 23 09:53:57 2017
-%% Update Count     : 1399
+%% Last Modified On : Wed Apr  5 23:19:40 2017
+%% Update Count     : 1412
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -50,5 +50,5 @@
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\CFADefaultStyle										% use default CFA format-style
+\CFAStyle												% use default CFA format-style
 
 % inline code ©...© (copyright symbol) emacs: C-q M-)
@@ -154,5 +154,5 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 #include <fstream>
 int main( void ) {
@@ -160,5 +160,5 @@
 	®sout | x | y | z | endl;®
 }
-\end{lstlisting}
+\end{cfa}
 &
 \begin{lstlisting}
@@ -245,9 +245,9 @@
 For example, the C math-library provides the following routines for computing the absolute value of the basic types: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©.
 Whereas, \CFA wraps each of these routines into ones with the common name ©abs©:
-\begin{lstlisting}
+\begin{cfa}
 char abs( char );
-extern "C" {
+®extern "C" {®
 int abs( int );					§\C{// use default C routine for int}§
-} // extern "C"
+®}® // extern "C"
 long int abs( long int );
 long long int abs( long long int );
@@ -258,5 +258,5 @@
 double _Complex abs( double _Complex );
 long double _Complex abs( long double _Complex );
-\end{lstlisting}
+\end{cfa}
 The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
 Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
@@ -273,7 +273,7 @@
 
 The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg:
-\begin{lstlisting}
+\begin{cfa}
 cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
-\end{lstlisting}
+\end{cfa}
 \CFA programs having the following ©gcc© flags turned on:
 \begin{description}
@@ -352,5 +352,5 @@
 These preprocessor variables allow conditional compilation of programs that must work differently in these situations.
 For example, to toggle between C and \CFA extensions, using the following:
-\begin{lstlisting}
+\begin{cfa}
 #ifndef __CFORALL__
 #include <stdio.h>				§\C{// C header file}§
@@ -358,12 +358,12 @@
 #include <fstream>				§\C{// \CFA header file}§
 #endif
-\end{lstlisting}
+\end{cfa}
 which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}. 
 
 
-\section{Underscores in Constants}
+\section{Constants Underscores}
 
 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg:
-\begin{lstlisting}
+\begin{cfa}
 2®_®147®_®483®_®648;			§\C{// decimal constant}§
 56_ul;							§\C{// decimal unsigned long constant}§
@@ -376,5 +376,5 @@
 0x_1.ffff_ffff_p_128_l;			§\C{// hexadecimal floating point long constant}§
 L_"\x_ff_ee";					§\C{// wide character constant}§
-\end{lstlisting}
+\end{cfa}
 The rules for placement of underscores is as follows:
 \begin{enumerate}
@@ -396,4 +396,30 @@
 
 
+\section{Backquote Identifiers}
+\label{s:BackquoteIdentifiers}
+
+\CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism:
+\begin{cfa}
+int ®`®otype®`® = 3;			§\C{// make keyword an identifier}§
+double ®`®choose®`® = 3.5;
+\end{cfa}
+Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name.
+Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©:
+\begin{cfa}
+// include file uses the CFA keyword "otype".
+#if ! defined( otype )			§\C{// nesting ?}§
+#define otype `otype`
+#define __CFA_BFD_H__
+#endif // ! otype
+
+#include_next <bfd.h>			§\C{// must have internal check for multiple expansion}§
+
+#if defined( otype ) && defined( __CFA_BFD_H__ )	§\C{// reset only if set}§
+#undef otype
+#undef __CFA_BFD_H__
+#endif // otype && __CFA_BFD_H__
+\end{cfa}
+
+
 \section{Declarations}
 \label{s:Declarations}
@@ -403,7 +429,7 @@
 \begin{quote2}
 \begin{tabular}{@{}ll@{}}
-\begin{lstlisting}
+\begin{cfa}
 int *x[5]
-\end{lstlisting}
+\end{cfa}
 &
 \raisebox{-0.75\totalheight}{\input{Cdecl}}
@@ -414,8 +440,8 @@
 Another example of confusion results from the fact that a routine name and its parameters are embedded within the return type, mimicking the way the return value is used at the routine's call site.
 For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
-\begin{lstlisting}
+\begin{cfa}
 int (*f())[5] {...};			§\C{}§
 ... (*f())[3] += 1;
-\end{lstlisting}
+\end{cfa}
 Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
 While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice.
@@ -428,15 +454,15 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 ß[5] *ß ®int® x1;
 ß* [5]ß ®int® x2;
 ß[* [5] int]ß f®( int p )®;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 ®int® ß*ß x1 ß[5]ß;
 ®int® ß(*ßx2ß)[5]ß;
 ßint (*ßf®( int p )®ß)[5]ß;
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -448,11 +474,11 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 ®*® int x, y;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 int ®*®x, ®*®y;
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -461,13 +487,13 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 ®*® int x;
 int y;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 int ®*®x, y;
 
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -477,5 +503,5 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 [ 5 ] int z;
 [ 5 ] * char w;
@@ -486,7 +512,7 @@
 	[ 5 ] * int f2;
 };
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 int z[ 5 ];
 char *w[ 5 ];
@@ -497,7 +523,7 @@
 	int *f2[ 5 ]
 };
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 // array of 5 integers
 // array of 5 pointers to char
@@ -508,5 +534,5 @@
 
 
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -516,18 +542,18 @@
 \begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
 \multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 const * const int x;
 const * [ 5 ] const int y;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 int const * const x;
 const int (* const y)[ 5 ]
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 // const pointer to const integer
 // const pointer to array of 5 const integers
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -537,18 +563,18 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 extern [ 5 ] int x;
 static * const int y;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 int extern x[ 5 ];
 const int static *y;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 // externally visible array of 5 integers
 // internally visible pointer to constant int
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -557,10 +583,10 @@
 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}}
 \eg:
-\begin{lstlisting}
+\begin{cfa}
 x;								§\C{// int x}§
 *y;								§\C{// int *y}§
 f( p1, p2 );					§\C{// int f( int p1, int p2 );}§
 f( p1, p2 ) {}					§\C{// int f( int p1, int p2 ) {}}§
-\end{lstlisting}
+\end{cfa}
 
 Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
@@ -583,19 +609,19 @@
 \begin{quote2}
 \begin{tabular}{@{}lll@{}}
-\begin{lstlisting}
+\begin{cfa}
 int x;
 x = 3;
 int y;
 y = x;
-\end{lstlisting}
+\end{cfa}
 &
 \raisebox{-0.45\totalheight}{\input{pointer1}}
 &
-\begin{lstlisting}
+\begin{cfa}
 int * ®const® x = (int *)100
 *x = 3;			// implicit dereference
 int * ®const® y = (int *)104;
 *y = *x;		// implicit dereference
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -606,17 +632,17 @@
 \begin{quote2}
 \begin{tabular}{@{}l|l@{}}
-\begin{lstlisting}
+\begin{cfa}
 lda		r1,100			// load address of x
 ld		r2,(r1)			  // load value of x
 lda		r3,104			// load address of y
 st		r2,(r3)			  // store x into y
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 
 ld		r2,(100)		// load value of x
 
 st		r2,(104)		// store x into y
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -629,5 +655,5 @@
 \begin{quote2}
 \begin{tabular}{@{}ll@{}}
-\begin{lstlisting}
+\begin{cfa}
 int x, y, ®*® p1, ®*® p2, ®**® p3;
 p1 = ®&®x;		 // p1 points to x
@@ -635,5 +661,5 @@
 p1 = ®&®y;		 // p1 points to y
 p3 = &p2;		// p3 points to p2
-\end{lstlisting}
+\end{cfa}
 &
 \raisebox{-0.45\totalheight}{\input{pointer2.pstex_t}}
@@ -643,35 +669,35 @@
 Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location.
 In many cases, a compiler might be able to infer the meaning:
-\begin{lstlisting}
+\begin{cfa}
 p2 = p1 + x;					§\C{// compiler infers *p2 = *p1 + x;}§
-\end{lstlisting}
+\end{cfa}
 because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
 \Index*{Algol68}~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage.
 However, in C, the following cases are ambiguous, especially with pointer arithmetic:
-\begin{lstlisting}
+\begin{cfa}
 p1 = p2;						§\C{// p1 = p2\ \ or\ \ *p1 = *p2}§
 p1 = p1 + 1;					§\C{// p1 = p1 + 1\ \ or\ \ *p1 = *p1 + 1}§
-\end{lstlisting}
+\end{cfa}
 
 Most languages pick one meaning as the default and the programmer explicitly indicates the other meaning to resolve the address-duality ambiguity\index{address! ambiguity}.
 In C, the default meaning for pointers is to manipulate the pointer's address and the pointed-to value is explicitly accessed by the dereference operator ©*©.
-\begin{lstlisting}
+\begin{cfa}
 p1 = p2;						§\C{// pointer address assignment}§
 *p1 = *p1 + 1;					§\C{// pointed-to value assignment / operation}§
-\end{lstlisting}
+\end{cfa}
 which works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
 
 However, in most other situations, the pointed-to value is requested more often than the pointer address.
-\begin{lstlisting}
+\begin{cfa}
 *p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15);
-\end{lstlisting}
+\end{cfa}
 In this case, it is tedious to explicitly write the dereferencing, and error prone when pointer arithmetic is allowed.
 It is better to have the compiler generate the dereferencing and have no implicit pointer arithmetic:
-\begin{lstlisting}
+\begin{cfa}
 p2 = ((p1 + p2) * (p3 - p1)) / (p3 - 15);
-\end{lstlisting}
+\end{cfa}
 
 To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} denoted by ©&©.
-\begin{lstlisting}
+\begin{cfa}
 int x, y, ®&® r1, ®&® r2, ®&&® r3;
 ®&®r1 = &x;						§\C{// r1 points to x}§
@@ -680,15 +706,15 @@
 ®&&®r3 = ®&®&r2;				§\C{// r3 points to r2}§
 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§
-\end{lstlisting}
+\end{cfa}
 Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
 Hence, a reference behaves like the variable name for the current variable it is pointing-to.
 The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, \eg:
-\begin{lstlisting}
+\begin{cfa}
 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);
-\end{lstlisting}
+\end{cfa}
 is rewritten as:
-\begin{lstlisting}
+\begin{cfa}
 ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
-\end{lstlisting}
+\end{cfa}
 When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.\footnote{
 The unary ©&© operator yields the address of its operand.
@@ -696,13 +722,13 @@
 If the operand is the result of a unary ©*© operator, neither that operator nor the ©&© operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.~\cite[\S~6.5.3.2--3]{C11}}
 Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}):
-\begin{lstlisting}
+\begin{cfa}
 (&®*®)r1 = &x;					§\C{// (\&*) cancel giving variable r1 not variable pointed-to by r1}§
-\end{lstlisting}
+\end{cfa}
 Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
-\begin{lstlisting}
+\begin{cfa}
 (&(&®*®)®*®)r3 = &(&®*®)r2;		§\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving variable r3}§
-\end{lstlisting}
+\end{cfa}
 Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses.
-\begin{lstlisting}
+\begin{cfa}
 int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
 		 &r1 = x,    &&r2 = r1,   &&&r3 = r2;
@@ -714,5 +740,5 @@
 &&r3 = ...;						§\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§
 &&&r3 = p3;						§\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
-\end{lstlisting}
+\end{cfa}
 Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one.
 That is, all implicit dereferencing and any cancellation is carried out prior to the start of the program, so reference performance is equivalent to pointer performance.
@@ -724,5 +750,5 @@
 
 As for a pointer, a reference may have qualifiers:
-\begin{lstlisting}
+\begin{cfa}
 const int cx = 5;				§\C{// cannot change cx;}§
 const int & cr = cx;			§\C{// cannot change what cr points to}§
@@ -734,9 +760,9 @@
 crc = 7;						§\C{// error, cannot change cx}§
 ®&®crc = &cx;					§\C{// error, cannot change crc}§
-\end{lstlisting}
+\end{cfa}
 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, \eg:
-\begin{lstlisting}
+\begin{cfa}
 int & const r = *0;				§\C{// where 0 is the int * zero}§
-\end{lstlisting}
+\end{cfa}
 Otherwise, the compiler is managing the addresses for type ©& const© not the programmer, and by a programming discipline of only using references with references, address errors can be prevented.
 Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
@@ -746,13 +772,13 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 ®const® * ®const® * const int ccp;
 ®const® & ®const® & const int ccr;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 const int * ®const® * ®const® ccp;
 
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -762,33 +788,33 @@
 There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding.
 For reference initialization (like pointer), the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}).
-\begin{lstlisting}
+\begin{cfa}
 int * p = &x;					§\C{// both \&x and x are possible interpretations}§
 int & r = x;					§\C{// x unlikely interpretation, because of auto-dereferencing}§
-\end{lstlisting}
+\end{cfa}
 Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression.
 Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator.
-\begin{lstlisting}
+\begin{cfa}
 int & f( int & rp );			§\C{// reference parameter and return}§
 z = f( x ) + f( y );			§\C{// reference operator added, temporaries needed for call results}§
-\end{lstlisting}
+\end{cfa}
 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©rp© can be locally reassigned within ©f©.
 Since ©?+?© takes its arguments by value, the references returned from ©f© are used to initialize compiler generated temporaries with value semantics that copy from the references.
 
 When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
-\begin{lstlisting}
+\begin{cfa}
 void f( ®const® int & crp );
 void g( ®const® int * cpp );
 f( 3 );			  g( &3 );
 f( x + y );		g( &(x + y) );
-\end{lstlisting}
+\end{cfa}
 Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
 (The ©&© is necessary for the pointer parameter to make the types match, and is a common requirement for a C programmer.)
 \CFA \emph{extends} this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed-to by the reference parameter and can be changed.
-\begin{lstlisting}
+\begin{cfa}
 void f( int & rp );
 void g( int * pp );
 f( 3 );			  g( &3 );		§\C{// compiler implicit generates temporaries}§
 f( x + y );		g( &(x + y) );	§\C{// compiler implicit generates temporaries}§
-\end{lstlisting}
+\end{cfa}
 Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
 This conversion attempts to address the \newterm{const hell} problem, when the innocent addition of a ©const© qualifier causes a cascade of type failures, requiring an unknown number of additional ©const© qualifiers, until it is discovered a ©const© qualifier cannot be added and all the ©const© qualifiers must be removed.}
@@ -796,5 +822,5 @@
 
 While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine variables in an inconsistent way: a routine variable is both a pointer and a reference (particle and wave).
-\begin{lstlisting}
+\begin{cfa}
 void f( int p ) {...}
 void (*fp)( int ) = &f;			§\C{// pointer initialization}§
@@ -802,41 +828,15 @@
 (*fp)(3);						§\C{// pointer invocation}§
 fp(3);							§\C{// reference invocation}§
-\end{lstlisting}
+\end{cfa}
 A routine variable is best described by a ©const© reference:
-\begin{lstlisting}
+\begin{cfa}
 const void (&fp)( int ) = f;
 fp( 3 );
 fp = ...						§\C{// error, cannot change code}§
 &fp = ...;						§\C{// changing routine reference}§
-\end{lstlisting}
+\end{cfa}
 because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{
 Dynamic code rewriting is possible but only in special circumstances.}
 \CFA allows this additional use of references for routine variables in an attempt to give a more consistent meaning for them.
-
-
-\section{Backquote Identifiers}
-\label{s:BackquoteIdentifiers}
-
-\CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism:
-\begin{lstlisting}
-int `otype` = 3;				// make keyword an identifier
-double `choose` = 3.5;
-\end{lstlisting}
-Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name.
-Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©:
-\begin{lstlisting}
-// include file uses the CFA keyword "otype".
-#if ! defined( otype )			// nesting ?
-#define otype `otype`
-#define __CFA_BFD_H__
-#endif // ! otype
-
-#include_next <bfd.h>			// must have internal check for multiple expansion
-
-#if defined( otype ) && defined( __CFA_BFD_H__ )	// reset only if set
-#undef otype
-#undef __CFA_BFD_H__
-#endif // otype && __CFA_BFD_H__
-\end{lstlisting}
 
 
@@ -847,13 +847,13 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 y = (®* int®)x;
 i = sizeof(®[ 5 ] * int®);
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 y = (®int *®)x;
 i = sizeof(®int *[ 5 ]®);
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -864,9 +864,9 @@
 \CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax.
 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
-\begin{lstlisting}
+\begin{cfa}
 ®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
 	§\emph{routine body}§
 }
-\end{lstlisting}
+\end{cfa}
 where routine ©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.
@@ -876,31 +876,31 @@
 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, \eg:
-\begin{lstlisting}
+\begin{cfa}
 ®extern® [ int x ] g( int y ) {§\,§}
-\end{lstlisting}
+\end{cfa}
 Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified;
 in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
-\begin{lstlisting}
+\begin{cfa}
 [§\,§] g();						§\C{// no input or output parameters}§
 [ void ] g( void );				§\C{// no input or output parameters}§
-\end{lstlisting}
+\end{cfa}
 
 Routine f is called as follows:
-\begin{lstlisting}
+\begin{cfa}
 [ i, j, ch ] = f( 3, 'a', ch );
-\end{lstlisting}
+\end{cfa}
 The list of return values from f and the grouping on the left-hand side of the assignment is called a \newterm{return list} and discussed in Section 12.
 
 \CFA style declarations cannot be used to declare parameters for K\&R style routine definitions because of the following ambiguity:
-\begin{lstlisting}
+\begin{cfa}
 int (*f(x))[ 5 ] int x; {}
-\end{lstlisting}
+\end{cfa}
 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.
 As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity:
-\begin{lstlisting}
+\begin{cfa}
 typedef int foo;
 int f( int (* foo) );			§\C{// foo is redefined as a parameter name}§
-\end{lstlisting}
+\end{cfa}
 The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
 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 qualifier characters appearing to the right of the type name.
@@ -908,14 +908,14 @@
 
 C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
-\begin{lstlisting}
+\begin{cfa}
 [ int ] f( * int, int * );		§\C{// returns an integer, accepts 2 pointers to integers}§
 [ * int, int * ] f( int );		§\C{// returns 2 pointers to integers, accepts an integer}§
-\end{lstlisting}
+\end{cfa}
 The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in:
-\begin{lstlisting}
+\begin{cfa}
 #define ptoa( n, d ) int (*n)[ d ]
 int f( ptoa( p, 5 ) ) ...		§\C{// expands to int f( int (*p)[ 5 ] )}§
 [ int ] f( ptoa( p, 5 ) ) ...	§\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
-\end{lstlisting}
+\end{cfa}
 Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
 
@@ -924,5 +924,5 @@
 
 \Index{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:
-\begin{lstlisting}
+\begin{cfa}
 int f() {
 	int x;
@@ -930,9 +930,9 @@
 	return x;
 }
-\end{lstlisting}
+\end{cfa}
 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:
 \newline
 \begin{minipage}{\linewidth}
-\begin{lstlisting}
+\begin{cfa}
 ®[ int x, int y ]® f() {
 	int z;
@@ -940,14 +940,14 @@
 	®return;® §\C{// implicitly return x, y}§
 }
-\end{lstlisting}
+\end{cfa}
 \end{minipage}
 \newline
 When the return is encountered, the current values of ©x© and ©y© are returned to the calling routine.
 As well, ``falling off the end'' of a routine without a ©return© statement is permitted, as in:
-\begin{lstlisting}
+\begin{cfa}
 [ int x, int y ] f() {
 	...
 } §\C{// implicitly return x, y}§
-\end{lstlisting}
+\end{cfa}
 In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
 
@@ -957,10 +957,10 @@
 The syntax of the new routine prototype declaration follows directly from the new routine definition syntax;
 as well, parameter names are optional, \eg:
-\begin{lstlisting}
+\begin{cfa}
 [ int x ] f ();					§\C{// returning int with no parameters}§
 [ * int ] g (int y);			§\C{// returning pointer to int with int parameter}§
 [ ] h (int,char);				§\C{// returning no result with int and char parameters}§
 [ * int,int ] j (int);			§\C{// returning pointer to int and int, with int parameter}§
-\end{lstlisting}
+\end{cfa}
 This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
 It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \eg:
@@ -968,18 +968,18 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 [ int ] f(int), g;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 int f(int), g(int);
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
 Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:
-\begin{lstlisting}
+\begin{cfa}
 extern [ int ] f (int);
 static [ int ] g (int);
-\end{lstlisting}
+\end{cfa}
 
 
@@ -987,15 +987,15 @@
 
 The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
-\begin{lstlisting}
+\begin{cfa}
 * [ int x ] () fp;			§\C{// pointer to routine returning int with no parameters}§
 * [ * int ] (int y) gp;		§\C{// pointer to routine returning pointer to int with int parameter}§
 * [ ] (int,char) hp;		§\C{// pointer to routine returning no result with int and char parameters}§
 * [ * int,int ] (int) jp;	§\C{// pointer to routine returning pointer to int and int, with int parameter}§
-\end{lstlisting}
+\end{cfa}
 While parameter names are optional, \emph{a routine name cannot be specified};
 for example, the following is incorrect:
-\begin{lstlisting}
+\begin{cfa}
 * [ int x ] f () fp;		§\C{// routine name "f" is not allowed}§
-\end{lstlisting}
+\end{cfa}
 
 
@@ -1010,15 +1010,15 @@
 provide the ability to specify an argument to a routine call using the parameter name rather than the position of the parameter.
 For example, given the routine:
-\begin{lstlisting}
+\begin{cfa}
 void p( int x, int y, int z ) {...}
-\end{lstlisting}
+\end{cfa}
 a positional call is:
-\begin{lstlisting}
+\begin{cfa}
 p( 4, 7, 3 );
-\end{lstlisting}
+\end{cfa}
 whereas a named (keyword) call may be:
-\begin{lstlisting}
+\begin{cfa}
 p( z : 3, x : 4, y : 7 ); 	§\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§
-\end{lstlisting}
+\end{cfa}
 Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters.
 The compiler rewrites a named call into a positional call.
@@ -1035,5 +1035,5 @@
 Unfortunately, named arguments do not work in C-style programming-languages because a routine prototype is not required to specify parameter names, nor do the names in the prototype have to match with the actual definition.
 For example, the following routine prototypes and definition are all valid.
-\begin{lstlisting}
+\begin{cfa}
 void p( int, int, int );			§\C{// equivalent prototypes}§
 void p( int x, int y, int z );
@@ -1041,5 +1041,5 @@
 void p( int z, int y, int x );
 void p( int q, int r, int s ) {}	§\C{// match with this definition}§
-\end{lstlisting}
+\end{cfa}
 Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming.
 Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports.
@@ -1048,5 +1048,5 @@
 Furthermore, named arguments do not work well in a \CFA-style programming-languages because they potentially introduces a new criteria for type matching.
 For example, it is technically possible to disambiguate between these two overloaded definitions of ©f© based on named arguments at the call site:
-\begin{lstlisting}
+\begin{cfa}
 int f( int i, int j );
 int f( int x, double y );
@@ -1055,9 +1055,9 @@
 f( x : 7, y : 8.1 );			§\C{// 2nd f}§
 f( 4, 5 ); 						§\C{// ambiguous call}§
-\end{lstlisting}
+\end{cfa}
 However, named arguments compound routine resolution in conjunction with conversions:
-\begin{lstlisting}
+\begin{cfa}
 f( i : 3, 5.7 );				§\C{// ambiguous call ?}§
-\end{lstlisting}
+\end{cfa}
 Depending on the cost associated with named arguments, this call could be resolvable or ambiguous.
 Adding named argument into the routine resolution algorithm does not seem worth the complexity.
@@ -1067,9 +1067,9 @@
 provide the ability to associate a default value with a parameter so it can be optionally specified in the argument list.
 For example, given the routine:
-\begin{lstlisting}
+\begin{cfa}
 void p( int x = 1, int y = 2, int z = 3 ) {...}
-\end{lstlisting}
+\end{cfa}
 the allowable positional calls are:
-\begin{lstlisting}
+\begin{cfa}
 p();							§\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
 p( 4 );							§\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
@@ -1084,5 +1084,5 @@
 p(  ,  , 4 );					§\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
 p(  ,  ,   );					§\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
-\end{lstlisting}
+\end{cfa}
 Here the missing arguments are inserted from the default values in the parameter list.
 The compiler rewrites missing default values into explicit positional arguments.
@@ -1106,9 +1106,9 @@
 
 Default values may only appear in a prototype versus definition context:
-\begin{lstlisting}
+\begin{cfa}
 void p( int x, int y = 2, int z = 3 );		§\C{// prototype: allowed}§
 void p( int, int = 2, int = 3 );			§\C{// prototype: allowed}§
 void p( int x, int y = 2, int z = 3 ) {}	§\C{// definition: not allowed}§
-\end{lstlisting}
+\end{cfa}
 The reason for this restriction is to allow separate compilation.
 Multiple prototypes with different default values is an error.
@@ -1117,14 +1117,14 @@
 Ellipse (``...'') arguments present problems when used with default arguments.
 The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities:
-\begin{lstlisting}
+\begin{cfa}
 p( /* positional */, ... , /* named */ );
 p( /* positional */, /* named */, ... );
-\end{lstlisting}
+\end{cfa}
 While it is possible to implement both approaches, the first possibly is more complex than the second, \eg:
-\begin{lstlisting}
+\begin{cfa}
 p( int x, int y, int z, ... );
 p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
 p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
-\end{lstlisting}
+\end{cfa}
 In the first call, it is necessary for the programmer to conceptually rewrite the call, changing named arguments into positional, before knowing where the ellipse arguments begin.
 Hence, this approach seems significantly more difficult, and hence, confusing and error prone.
@@ -1132,9 +1132,9 @@
 
 The problem is exacerbated with default arguments, \eg:
-\begin{lstlisting}
+\begin{cfa}
 void p( int x, int y = 2, int z = 3... );
 p( 1, 4, 5, 6, z : 3 );		§\C{// assume p( /* positional */, ... , /* named */ );}§
 p( 1, z : 3, 4, 5, 6 );		§\C{// assume p( /* positional */, /* named */, ... );}§
-\end{lstlisting}
+\end{cfa}
 The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
 therefore, argument 5 subsequently conflicts with the named argument z : 3.
@@ -1148,15 +1148,15 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{default arguments}}	& \multicolumn{1}{c}{\textbf{overloading}}	\\
-\begin{lstlisting}
+\begin{cfa}
 void p( int x, int y = 2, int z = 3 ) {...}
 
 
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 void p( int x, int y, int z ) {...}
 void p( int x ) { p( x, 2, 3 ); }
 void p( int x, int y ) { p( x, y, 3 ); }
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -1164,7 +1164,7 @@
 In general, overloading should only be used over default arguments if the body of the routine is significantly different.
 Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as:
-\begin{lstlisting}
+\begin{cfa}
 p( 1, /* default */, 5 );		§\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§
-\end{lstlisting}
+\end{cfa}
 
 Given the \CFA restrictions above, both named and default arguments are backwards compatible.
@@ -1186,5 +1186,5 @@
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}	& \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}	& \multicolumn{1}{|c}{\textbf{\CFA}}	\\
 \hline
-\begin{lstlisting}
+\begin{cfa}
 struct S {
 	enum C { R, G, B };
@@ -1203,7 +1203,7 @@
 	union U u;
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 enum C { R, G, B };
 union U { int i, j; };
@@ -1222,7 +1222,7 @@
 
 
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 struct S {
 	enum C { R, G, B };
@@ -1241,5 +1241,5 @@
 	union ®S.T.®U u;
 }
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \caption{Type Nesting / Qualification}
@@ -1254,10 +1254,10 @@
 While \CFA does not provide object programming by putting routines into structures, it does rely heavily on locally nested routines to redefine operations at or close to a call site.
 For example, the C quick-sort is wrapped into the following polymorphic \CFA routine:
-\begin{lstlisting}
+\begin{cfa}
 forall( otype T | { int ?<?( T, T ); } )
 void qsort( const T * arr, size_t dimension );
-\end{lstlisting}
+\end{cfa}
 which can be used to sort in ascending and descending order by locally redefining the less-than operator into greater-than.
-\begin{lstlisting}
+\begin{cfa}
 const unsigned int size = 5;
 int ia[size];
@@ -1268,10 +1268,10 @@
 	qsort( ia, size );	§\C{// sort descending order by local redefinition}§
 }
-\end{lstlisting}
+\end{cfa}
 
 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 Indexc{gcc})
-\begin{lstlisting}
+\begin{cfa}
 [* [int]( int )] foo() {		§\C{// int (*foo())( int )}§
 	int ®i® = 7;
@@ -1286,5 +1286,5 @@
     sout | fp( 3 ) | endl;
 }
-\end{lstlisting}
+\end{cfa}
 because 
 
@@ -1298,15 +1298,15 @@
 A list of such elements is called a \newterm{lexical list}.
 The general syntax of a lexical list is:
-\begin{lstlisting}
+\begin{cfa}
 [ §\emph{exprlist}§ ]
-\end{lstlisting}
+\end{cfa}
 where ©$\emph{exprlist}$© is a list of one or more expressions separated by commas.
 The brackets, ©[]©, allow differentiating between lexical lists and expressions containing the C comma operator.
 The following are examples of lexical lists:
-\begin{lstlisting}
+\begin{cfa}
 [ x, y, z ]
 [ 2 ]
 [ v+w, x*y, 3.14159, f() ]
-\end{lstlisting}
+\end{cfa}
 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.
 Note, a tuple is not a record (structure);
@@ -1318,23 +1318,23 @@
 Tuple variables and types can be used anywhere lists of conventional variables and types can be used.
 The general syntax of a tuple type is:
-\begin{lstlisting}
+\begin{cfa}
 [ §\emph{typelist}§ ]
-\end{lstlisting}
+\end{cfa}
 where ©$\emph{typelist}$© is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
 Examples of tuple types include:
-\begin{lstlisting}
+\begin{cfa}
 [ unsigned int, char ]
 [ double, double, double ]
 [ * int, int * ]		§\C{// mix of CFA and ANSI}§
 [ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ]
-\end{lstlisting}
+\end{cfa}
 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.
 
 Examples of declarations using tuple types are:
-\begin{lstlisting}
+\begin{cfa}
 [ int, int ] x;			§\C{// 2 element tuple, each element of type int}§
 * [ char, char ] y;		§\C{// pointer to a 2 element tuple}§
 [ [ int, int ] ] z ([ int, int ]);
-\end{lstlisting}
+\end{cfa}
 The last example declares an external routine that expects a 2 element tuple as an input parameter and returns a 2 element tuple as its result.
 
@@ -1342,11 +1342,11 @@
 In unambiguous situations, the tuple brackets may be omitted, \eg a tuple that appears as an argument may have its
 square brackets omitted for convenience; therefore, the following routine invocations are equivalent:
-\begin{lstlisting}
+\begin{cfa}
 f( [ 1, x+2, fred() ] );
 f( 1, x+2, fred() );
-\end{lstlisting}
+\end{cfa}
 Also, a tuple or a tuple variable may be used to supply all or part of an argument list for a routine expecting multiple input parameters or for a routine expecting a tuple as an input parameter.
 For example, the following are all legal:
-\begin{lstlisting}
+\begin{cfa}
 [ int, int ] w1;
 [ int, int, int ] w2;
@@ -1361,5 +1361,5 @@
 g( 1, w1 );
 g( w2 );
-\end{lstlisting}
+\end{cfa}
 Note, in all cases 3 arguments are supplied even though the syntax may appear to supply less than 3. As mentioned, a
 tuple does not have structure like a record; a tuple is simply converted into a list of components.
@@ -1371,8 +1371,8 @@
 A tuple can contain a C comma expression, provided the expression containing the comma operator is enclosed in parentheses.
 For instance, the following tuples are equivalent:
-\begin{lstlisting}
+\begin{cfa}
 [ 1, 3, 5 ]
 [ 1, (2, 3), 5 ]
-\end{lstlisting}
+\end{cfa}
 The second element of the second tuple is the expression (2, 3), which yields the result 3.
 This requirement is the same as for comma expressions in argument lists.
@@ -1380,16 +1380,16 @@
 Type qualifiers, i.e., const and volatile, may modify a tuple type.
 The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, \eg:
-\begin{lstlisting}
+\begin{cfa}
 const volatile [ int, float, const int ] x;
-\end{lstlisting}
+\end{cfa}
 is equivalent to:
-\begin{lstlisting}
+\begin{cfa}
 [ const volatile int, const volatile float, const volatile int ] x;
-\end{lstlisting}
+\end{cfa}
 Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, \eg:
-\begin{lstlisting}
+\begin{cfa}
 extern [ int, int ] w1;
 static [ int, int, int ] w2;
-\end{lstlisting}
+\end{cfa}
 \begin{rationale}
 Unfortunately, C's syntax for subscripts precluded treating them as tuples.
@@ -1405,20 +1405,20 @@
 In addition, the coercion of dereferencing can be performed on a tuple variable to yield its value(s), as for other variables.
 A \newterm{closing coercion} takes a set of values and converts it into a tuple value, which is a contiguous set of values, as in:
-\begin{lstlisting}
+\begin{cfa}
 [ int, int, int, int ] w;
 w = [ 1, 2, 3, 4 ];
-\end{lstlisting}
+\end{cfa}
 First the right-hand tuple is closed into a tuple value and then the tuple value is assigned.
 
 An \newterm{opening coercion} is the opposite of closing; a tuple value is converted into a tuple of values, as in:
-\begin{lstlisting}
+\begin{cfa}
 [ a, b, c, d ] = w
-\end{lstlisting}
+\end{cfa}
 ©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:
-\begin{lstlisting}
+\begin{cfa}
 [ a, b, c, d ] = [ 1, [ 2, 3 ], 4 ];
-\end{lstlisting}
+\end{cfa}
 First the right-hand tuple is flattened and then the values are assigned individually.
 Flattening is also performed on tuple types.
@@ -1429,9 +1429,9 @@
 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 ]©.
 In the following example, the last assignment illustrates all the tuple coercions:
-\begin{lstlisting}
+\begin{cfa}
 [ int, int, int, int ] w = [ 1, 2, 3, 4 ];
 int x = 5;
 [ x, w ] = [ w, x ];		§\C{// all four tuple coercions}§
-\end{lstlisting}
+\end{cfa}
 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 ]©.
@@ -1448,7 +1448,7 @@
 \CFA permits assignment to several variables at once using mass assignment~\cite{CLU}.
 Mass assignment has the following form:
-\begin{lstlisting}
+\begin{cfa}
 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;
-\end{lstlisting}
+\end{cfa}
 \index{lvalue}
 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.
@@ -1457,26 +1457,26 @@
 
 Mass assignment has parallel semantics, \eg the statement:
-\begin{lstlisting}
+\begin{cfa}
 [ x, y, z ] = 1.5;
-\end{lstlisting}
+\end{cfa}
 is equivalent to:
-\begin{lstlisting}
+\begin{cfa}
 x = 1.5; y = 1.5; z = 1.5;
-\end{lstlisting}
+\end{cfa}
 This semantics is not the same as the following in C:
-\begin{lstlisting}
+\begin{cfa}
 x = y = z = 1.5;
-\end{lstlisting}
+\end{cfa}
 as conversions between intermediate assignments may lose information.
 A more complex example is:
-\begin{lstlisting}
+\begin{cfa}
 [ i, y[i], z ] = a + b;
-\end{lstlisting}
+\end{cfa}
 which is equivalent to:
-\begin{lstlisting}
+\begin{cfa}
 t = a + b;
 a1 = &i; a2 = &y[i]; a3 = &z;
 *a1 = t; *a2 = t; *a3 = t;
-\end{lstlisting}
+\end{cfa}
 The temporary ©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.
@@ -1488,39 +1488,39 @@
 \CFA also supports the assignment of several values at once, known as multiple assignment~\cite{CLU,Galletly96}.
 Multiple assignment has the following form:
-\begin{lstlisting}
+\begin{cfa}
 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ];
-\end{lstlisting}
+\end{cfa}
 \index{lvalue}
 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.
 An example of multiple assignment is:
-\begin{lstlisting}
+\begin{cfa}
 [ x, y, z ] = [ 1, 2, 3 ];
-\end{lstlisting}
+\end{cfa}
 Here, the values ©1©, ©2© and ©3© are assigned, respectively, to the variables ©x©, ©y© and ©z©.
  A more complex example is:
-\begin{lstlisting}
+\begin{cfa}
 [ i, y[ i ], z ] = [ 1, i, a + b ];
-\end{lstlisting}
+\end{cfa}
 Here, the values ©1©, ©i© and ©a + b© are assigned to the variables ©i©, ©y[i]© and ©z©, respectively.
  Note, the parallel semantics of
 multiple assignment ensures:
-\begin{lstlisting}
+\begin{cfa}
 [ x, y ] = [ y, x ];
-\end{lstlisting}
+\end{cfa}
 correctly interchanges (swaps) the values stored in ©x© and ©y©.
 The following cases are errors:
-\begin{lstlisting}
+\begin{cfa}
 [ a, b, c ] = [ 1, 2, 3, 4 ];
 [ a, b, c ] = [ 1, 2 ];
-\end{lstlisting}
+\end{cfa}
 because the number of entities in the left-hand tuple is unequal with the right-hand tuple.
 
 As for all tuple contexts in C, side effects should not be used because C does not define an ordering for the evaluation of the elements of a tuple;
 both these examples produce indeterminate results:
-\begin{lstlisting}
+\begin{cfa}
 f( x++, x++ );				§\C{// C routine call with side effects in arguments}§
 [ v1, v2 ] = [ x++, x++ ];	§\C{// side effects in righthand side of multiple assignment}§
-\end{lstlisting}
+\end{cfa}
 
 
@@ -1529,15 +1529,15 @@
 As in C, \CFA mass and multiple assignments can be cascaded, producing cascade assignment.
 Cascade assignment has the following form:
-\begin{lstlisting}
+\begin{cfa}
 §\emph{tuple}§ = §\emph{tuple}§ = ... = §\emph{tuple}§;
-\end{lstlisting}
+\end{cfa}
 and it has the same parallel semantics as for mass and multiple assignment.
 Some examples of cascade assignment are:
-\begin{lstlisting}
+\begin{cfa}
 x1 = y1 = x2 = y2 = 0;
 [ x1, y1 ] = [ x2, y2 ] = [ x3, y3 ];
 [ x1, y1 ] = [ x2, y2 ] = 0;
 [ x1, y1 ] = z = 0;
-\end{lstlisting}
+\end{cfa}
 As in C, the rightmost assignment is performed first, i.e., assignment parses right to left.
 
@@ -1546,5 +1546,5 @@
 
 C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg:
-\begin{lstlisting}
+\begin{cfa}
 struct {
 	int f1;					§\C{// named field}§
@@ -1555,13 +1555,13 @@
 	int (*)(int);			§\C{// disallowed, unnamed field}§
 };
-\end{lstlisting}
+\end{cfa}
 This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed.
 As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size.
 A list of unnamed fields is also supported, \eg:
-\begin{lstlisting}
+\begin{cfa}
 struct {
 	int , , ;				§\C{// 3 unnamed fields}§
 }
-\end{lstlisting}
+\end{cfa}
 
 
@@ -1570,13 +1570,13 @@
 Tuples may be used to select multiple fields of a record by field name.
 Its general form is:
-\begin{lstlisting}
+\begin{cfa}
 §\emph{expr}§ . [ §\emph{fieldlist}§ ]
 §\emph{expr}§ -> [ §\emph{fieldlist}§ ]
-\end{lstlisting}
+\end{cfa}
 \emph{expr} is any expression yielding a value of type record, \eg ©struct©, ©union©.
 Each element of \emph{ fieldlist} is an element of the record specified by \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:
-\begin{lstlisting}
+\begin{cfa}
 struct s {
 	int f1, f2;
@@ -1586,10 +1586,10 @@
 v.[ f3, f1, f2 ] = ['x', 11, 17 ];	§\C{// equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17}§
 f( v.[ f3, f1, f2 ] );				§\C{// equivalent to f( v.f3, v.f1, v.f2 )}§
-\end{lstlisting}
+\end{cfa}
 Note, the fields appearing in a record-field tuple may be specified in any order;
 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:
-\begin{lstlisting}
+\begin{cfa}
 struct inner {
 	int f2, f3;
@@ -1602,5 +1602,5 @@
 
 o.[ f1, i.[ f2, f3 ], f4 ] = [ 11, 12, 13, 3.14159 ];
-\end{lstlisting}
+\end{cfa}
 
 
@@ -1617,5 +1617,5 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 ®L1:® do {
 	®L2:® while ( ... ) {
@@ -1627,7 +1627,7 @@
 	} // while
 } while ( ... );
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 do {
 	while ( ... ) {
@@ -1639,5 +1639,5 @@
 	L2: ; }
 L1: ; } while ( ... );
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -1648,5 +1648,5 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 ®L1:® {
 	... §declarations§ ...
@@ -1665,7 +1665,7 @@
 	} // switch
 } // compound
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 {
 	... §declarations§ ...
@@ -1684,5 +1684,5 @@
 	} L2: ;
 } L1: ;
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -1714,5 +1714,5 @@
 \emph{falls through} to the next ©case© clause in the ©switch© statement;
 to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
-\begin{lstlisting}
+\begin{cfa}
 switch ( i ) {
   case 1:
@@ -1723,9 +1723,9 @@
 	break;	// exit switch statement
 }
-\end{lstlisting}
+\end{cfa}
 The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
-\begin{lstlisting}
+\begin{cfa}
 switch ( argc ) {
   case 3:
@@ -1738,7 +1738,7 @@
 	// usage message
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 
 if ( argc == 3 ) {
@@ -1751,5 +1751,5 @@
 	// usage message
 }
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -1757,5 +1757,5 @@
 This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
 C also uses fall-through to handle multiple case-values resulting in the same action:
-\begin{lstlisting}
+\begin{cfa}
 switch ( i ) {
   case 1: case 3: case 5:	// odd values
@@ -1766,5 +1766,5 @@
 	break;
 }
-\end{lstlisting}
+\end{cfa}
 However, this situation is handled in other languages without fall-through by allowing a list of case values.
 While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
@@ -1773,5 +1773,5 @@
 \item
 It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
-\begin{lstlisting}
+\begin{cfa}
 switch ( i ) {
   case 0:
@@ -1788,5 +1788,5 @@
 	} // while
 } // switch
-\end{lstlisting}
+\end{cfa}
 The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
 The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
@@ -1795,5 +1795,5 @@
 There are virtually no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
 Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
-\begin{lstlisting}
+\begin{cfa}
 register int n = (count + 7) / 8;
 switch ( count % 8 ) {
@@ -1808,5 +1808,5 @@
 		} while ( --n > 0 );
 }
-\end{lstlisting}
+\end{cfa}
 which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
 While efficient, this sort of special purpose usage is questionable:
@@ -1824,5 +1824,5 @@
 \item
 It is possible to place unreachable code at the start of a ©switch© statement, as in:
-\begin{lstlisting}
+\begin{cfa}
 switch ( x ) {
 	®int y = 1;®				§\C{// unreachable initialization}§
@@ -1835,5 +1835,5 @@
 	®x = z;®					§\C{// without fall through, z is uninitialized}§
 }
-\end{lstlisting}
+\end{cfa}
 While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
@@ -1858,11 +1858,11 @@
 Eliminating default fall-through has the greatest potential for affecting existing code.
 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, i.e., a list of ©case© clauses executing common code, \eg:
- \begin{lstlisting}
+\begin{cfa}
 case 1:  case 2:  case 3: ...
-\end{lstlisting}
+\end{cfa}
 still works.
 Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, e.g.:
-\begin{lstlisting}
+\begin{cfa}
 ®choose® ( i ) {
   case 1:  case 2:  case 3:
@@ -1878,5 +1878,5 @@
 	j = 3;
 }
-\end{lstlisting}
+\end{cfa}
 Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
 the implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
@@ -1893,5 +1893,5 @@
 Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
 Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
-\begin{lstlisting}
+\begin{cfa}
 switch ( x ) {
 	®int i = 0;®				§\C{// allowed only at start}§
@@ -1906,5 +1906,5 @@
   ...
 }
-\end{lstlisting}
+\end{cfa}
 \end{enumerate}
 
@@ -1919,5 +1919,5 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 switch ( i ) {
   case ®1, 3, 5®:
@@ -1926,7 +1926,7 @@
 	...
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 switch ( i ) {
   case 1: case 3 : case 5:
@@ -1935,7 +1935,7 @@
 	...
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 
 // odd values
@@ -1944,5 +1944,5 @@
 
 
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -1952,5 +1952,5 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{\hspace{2em}}}{\textbf{GNU C}}	\\
-\begin{lstlisting}
+\begin{cfa}
 switch ( i ) {
   case ®1~5:®
@@ -1959,7 +1959,7 @@
 	...
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 switch ( i )
   case ®1 ... 5®:
@@ -1968,7 +1968,7 @@
 	...
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 
 // 1, 2, 3, 4, 5
@@ -1977,11 +1977,11 @@
 
 
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
 Lists of subranges are also allowed.
-\begin{lstlisting}
+\begin{cfa}
 case ®1~5, 12~21, 35~42®:
-\end{lstlisting}
+\end{cfa}
 
 
@@ -1989,5 +1989,5 @@
 
 Exception handling provides two mechanism: change of control flow from a raise to a handler, and communication from the raise to the handler.
-\begin{lstlisting}
+\begin{cfa}
 exception void h( int i );
 exception int h( int i, double d );
@@ -2006,5 +2006,5 @@
 } finally {
 }
-\end{lstlisting}
+\end{cfa}
 So the type raised would be the mangled name of the exception prototype and that name would be matched at the handler clauses by comparing the strings.
 The arguments for the call would have to be packed in a message and unpacked at handler clause and then a call made to the handler.
@@ -2017,8 +2017,8 @@
 \CFA allows users to define new types using the keyword type.
 
-\begin{lstlisting}
+\begin{cfa}
 // SensorValue is a distinct type and represented as an int
 type SensorValue = int;
-\end{lstlisting}
+\end{cfa}
 
 A type definition is different from a typedef in C because a typedef just creates an alias for a type,  while Do.s type definition creates a distinct type.
@@ -2026,5 +2026,5 @@
 For example:
 
-\begin{lstlisting}
+\begin{cfa}
 type SensorValue = int;
 void printValue(int v) {...}
@@ -2039,5 +2039,5 @@
 
 process(s); // implicit conversion to int
-\end{lstlisting}
+\end{cfa}
 
 If SensorValue was defined with a typedef, then these two print functions would not have unique signatures.
@@ -2047,5 +2047,5 @@
 Users may override this and define a function that must be called to convert from one type to another.
 
-\begin{lstlisting}
+\begin{cfa}
 type SensorValue = int;
 // ()? is the overloaded conversion operator identifier
@@ -2058,5 +2058,5 @@
 SensorValue s = ...;
 process(s); // implicit call to conversion operator
-\end{lstlisting}
+\end{cfa}
 
 In many cases, it is not desired for the compiler to do this implicit conversion.
@@ -2064,5 +2064,5 @@
 Any places where the conversion is needed but not explicit (with a cast), will result in a compile-time error.
 
-\begin{lstlisting}
+\begin{cfa}
 type SensorValue = int;
 
@@ -2077,8 +2077,8 @@
 process(s); // implicit cast to int: compile-time error
 process((int) s); // explicit cast to int: calls conversion func
-\end{lstlisting}
+\end{cfa}
 
 The conversion may not require any code, but still need to be explicit; in that case, the syntax can be simplified to:
-\begin{lstlisting}
+\begin{cfa}
 type SensorValue = int;
 explicit SensorValue ()?(int);
@@ -2088,5 +2088,5 @@
 process(s); // compile-time error
 process((int) s); // type is converted, no function is called
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2096,5 +2096,5 @@
 A structure is defined with the same syntax as in C.
 When referring to a structure in \CFA, users may omit the struct keyword.
-\begin{lstlisting}
+\begin{cfa}
 struct Point {
 	double x;
@@ -2103,5 +2103,5 @@
 
 Point p = {0.0, 0.0};
-\end{lstlisting}
+\end{cfa}
 
 \CFA does not support inheritance among types, but instead uses composition to enable reuse of structure fields.
@@ -2110,5 +2110,5 @@
 Embedding types is achieved using anonymous members.
 For example, using Point from above:
-\begin{lstlisting}
+\begin{cfa}
 void foo(Point p);
 
@@ -2122,5 +2122,5 @@
 	cp.color = 0x33aaff; // color is accessed normally
 	foo(cp); // cp can be used directly as a Point
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2132,5 +2132,5 @@
 
 \begin{figure}
-\begin{lstlisting}
+\begin{cfa}
 struct Widget {
 	int id;
@@ -2174,5 +2174,5 @@
 ^bar; // explicit call to destructor
 ^?(bar); // explicit call to destructor
-\end{lstlisting}
+\end{cfa}
 \caption{Constructors and Destructors}
 \end{figure}
@@ -2211,5 +2211,5 @@
 If there is no single best valid interpretation, or if the best valid interpretation is ambiguous, then the resulting interpretation is ambiguous.
 For details about type inference and overload resolution, please see the \CFA Language Specification.
-\begin{lstlisting}
+\begin{cfa}
 int foo(int a, int b) {
 	float sum = 0.0;
@@ -2224,5 +2224,5 @@
 	...
 }
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2245,5 +2245,5 @@
 For example, to define the constants for a complex type, the programmer would define the following:
 
-\begin{lstlisting}
+\begin{cfa}
 struct Complex {
 	double real;
@@ -2263,5 +2263,5 @@
 ...
 }
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2271,9 +2271,9 @@
 Allowing overloading of variable names enables programmers to use the same name across multiple types, simplifying naming conventions and is compatible with the other overloading that is allowed.
 For example, a developer may want to do the following:
-\begin{lstlisting}
+\begin{cfa}
 int pi = 3;
 float pi = 3.14;
 char pi = .p.;
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2283,5 +2283,5 @@
 
 The examples below give some basic intuition about how the resolution works.
-\begin{lstlisting}
+\begin{cfa}
 // Choose the one with less conversions
 int doSomething(int value) {...} // option 1
@@ -2306,5 +2306,5 @@
 
 f = bar(d, e); // chooses option 5
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2376,5 +2376,5 @@
 These operators are called using the normal C syntax.
 
-\begin{lstlisting}
+\begin{cfa}
 type Complex = struct { // define a Complex type
 	double real;
@@ -2406,5 +2406,5 @@
 c = a + b;
 print(.sum = . + c);
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2415,24 +2415,24 @@
 \begin{tabular}{@{}l@{\hspace{3em}}ll@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}}	& \multicolumn{1}{c}{Indexc{gcc}} \\
-\begin{lstlisting}
+\begin{cfa}
 
 auto j = 3.0 * 4;
 int i;
 auto k = i;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 #define expr 3.0 * i
 typeof(expr) j = expr;
 int i;
 typeof(i) k = i;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 
 // use type of initialization expression
 
 // use type of primary variable
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -2451,12 +2451,12 @@
 Finally, ©auto© presents the programming problem of tracking down a type when the type is actually needed.
 For example, given
-\begin{lstlisting}
+\begin{cfa}
 auto j = ®...®
-\end{lstlisting}
+\end{cfa}
 and the need to write a routine to compute using ©j©
-\begin{lstlisting}
+\begin{cfa}
 void rtn( ®...® parm );
 rtn( j );
-\end{lstlisting}
+\end{cfa}
 A programmer must work backwards to determine the type of ©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.
@@ -2488,5 +2488,5 @@
 A simple example of using Do.s parametric polymorphism to create a generic swap function would look like this:
 
-\begin{lstlisting}
+\begin{cfa}
 generic(type T)
 void swap(T &a, T &b) {
@@ -2501,5 +2501,5 @@
 Point p1, p2;
 swap(p1, p2);
-\end{lstlisting}
+\end{cfa}
 
 Here, instead of specifying types for the parameters a and b, the function has a generic type parameter, type T.
@@ -2511,5 +2511,5 @@
 Some generic functions only work (or make sense) for any type that satisfies a given property.
 For example, here is a function to pick the minimum of two values of some type.
-\begin{lstlisting}
+\begin{cfa}
 generic (type T | bool ?<?(T, T) )
 
@@ -2517,5 +2517,5 @@
 	return a < b ? a : b;
 }
-\end{lstlisting}
+\end{cfa}
 
 It only makes sense to call min with values of a type that has an ordering: a way to decide whether one value is less than another.
@@ -2526,5 +2526,5 @@
 
 Bounds can also involve multiple types, and multiple requirements, as shown below:
-\begin{lstlisting}
+\begin{cfa}
 generic (type T, type U | { T foo(T, U); U bar(U); })
 
@@ -2532,5 +2532,5 @@
 	return foo(t, bar(u));
 }
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2546,5 +2546,5 @@
 This avoids repetition when a bound is used in many functions.
 Second, interfaces explicitly document the existence of a commonly used set of functionality, making programs easier to understand.
-\begin{lstlisting}
+\begin{cfa}
 generic (type T)
 interface Orderable {
@@ -2556,5 +2556,5 @@
 	return a < b ? a : b;
 }
-\end{lstlisting}
+\end{cfa}
 
 This definition of the interface Orderable makes the generic function min easier to read and understand.
@@ -2562,5 +2562,5 @@
 Interfaces can also build on top of other interfaces.
 For example:
-\begin{lstlisting}
+\begin{cfa}
 generic (type T | Orderable(T)
 interface FooBarable {
@@ -2568,5 +2568,5 @@
 	int Bar(T, T);
 };
-\end{lstlisting}
+\end{cfa}
 
 The FooBarable interface specifies all of the bounds of the Orderable interface, plus the additional bounds specified in its definition.
@@ -2579,5 +2579,5 @@
 Type synonyms can be defined generically using the typedef keyword together with a generic type annotation.
 These can be used to abbreviate complicated type expressions, especially in generic code.
-\begin{lstlisting}
+\begin{cfa}
 // typedef the generic function pointers for later use
 
@@ -2594,5 +2594,5 @@
 	if (p(array[i])) f(NULL, array[i]);
 }
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2608,5 +2608,5 @@
 The syntax for defining a generic type looks very similar to that of a generic function.
 Generic types support bounds and interfaces, using the same syntax as generic functions.
-\begin{lstlisting}
+\begin{cfa}
 generic (type T)
 struct LinkedListElem {
@@ -2632,5 +2632,5 @@
 	return false;
 }
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2655,5 +2655,5 @@
 An exception is thrown using a throw statement, which accepts one argument.
 
-\begin{lstlisting}
+\begin{cfa}
 	...
 
@@ -2661,5 +2661,5 @@
 
 	...
-\end{lstlisting}
+\end{cfa}
 
 An exception can be caught using a catch statement, which specifies the type of the exception it can catch.
@@ -2667,5 +2667,5 @@
 A guarded block is specified using the try keyword, followed by a block of code inside of curly braces.
 
-\begin{lstlisting}
+\begin{cfa}
 	...
 
@@ -2676,5 +2676,5 @@
 		printf(.caught an exception: %d\n., e);
 	}
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2691,5 +2691,5 @@
 Instead, it infers the type based on the return value, and then allocates space for the inferred type.
 
-\begin{lstlisting}
+\begin{cfa}
 float *f = malloc(); // allocates the size of a float
 
@@ -2699,10 +2699,10 @@
 
 struct S *s = malloc(); // allocates the size of a struct S
-\end{lstlisting}
+\end{cfa}
 
 In addition to the improved malloc, \CFA also provides a technique for combining allocation and initialization into one step, using the new function.
 For all constructors defined for a given type (see Operator Overloading), a corresponding call to new can be used to allocate and construct that type.
 
-\begin{lstlisting}
+\begin{cfa}
 type Complex = struct {
 	float real;
@@ -2737,5 +2737,5 @@
 }
 
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2764,19 +2764,19 @@
 The number 0 and 1 are treated specially in \CFA, and can be redefined as variables.
 One syntactic anomaly is when a field in an structure is names 0 or 1:
-\begin{lstlisting}
+\begin{cfa}
 struct S {
 	int 0, 1;
 } s;
-\end{lstlisting}
+\end{cfa}
 The problem occurs in accessing these fields using the selection operation ``©.©'':
-\begin{lstlisting}
+\begin{cfa}
 s.0 = 0;	// ambiguity with floating constant .0
 s.1 = 1;	// ambiguity with floating constant .1
-\end{lstlisting}
+\end{cfa}
 To make this work, a space is required after the field selection:
-\begin{lstlisting}
+\begin{cfa}
 ®s.§\textvisiblespace§0® = 0;
 ®s.§\textvisiblespace§1® = 1;
-\end{lstlisting}
+\end{cfa}
 While this syntax is awkward, it is unlikely many programmers will name fields of a structure 0 or 1.
 Like the \Index*[C++]{\CC} lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser.
@@ -2786,18 +2786,18 @@
 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}
+\begin{cfa}
 int *§\textvisiblespace§?()();	// declaration: space required after '*'
 *§\textvisiblespace§?()();		// expression: space required after '*'
-\end{lstlisting}
+\end{cfa}
 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 4 remaining cases occur in expressions:
-\begin{lstlisting}
+\begin{cfa}
 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}
+\end{cfa}
 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.
@@ -2835,10 +2835,10 @@
 Users of a monitor interact with it just like any structure, but the compiler handles code as needed to ensure mutual exclusion.
 An example of the definition of a monitor is shown here:
-\begin{lstlisting}
+\begin{cfa}
 type Account = monitor {
 	const unsigned long number; // account number
 	float balance; // account balance
 };
-\end{lstlisting}
+\end{cfa}
 
 Since a monitor structure includes an implicit locking mechanism, it does not make sense to copy a monitor;
@@ -2850,5 +2850,5 @@
 If multiple mutex parameters are specified, they will be locked in parameter order (\ie first parameter is locked first) and unlocked in the
 reverse order.
-\begin{lstlisting}
+\begin{cfa}
 // This function accesses a constant field, it does not require
 // mutual exclusion
@@ -2865,5 +2865,5 @@
 	return a.balance;
 }
-\end{lstlisting}
+\end{cfa}
 
 Often, one function using a monitor will call another function using that same monitor.
@@ -2873,5 +2873,5 @@
 An example of this situation is shown below:
 
-\begin{lstlisting}
+\begin{cfa}
 // deleting a job from a worker requires mutual exclusion
 
@@ -2887,5 +2887,5 @@
 	...
 }
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2895,5 +2895,5 @@
 A task provides mutual exclusion like a monitor, and also has its own execution state and a thread of control.
 Similar to a monitor, a task is defined like a structure:
-\begin{lstlisting}
+\begin{cfa}
 type Adder = task {
 	int *row;
@@ -2901,5 +2901,5 @@
 	int &subtotal;
 }
-\end{lstlisting}
+\end{cfa}
 
 A task may define a constructor, which will be called upon allocation and run on the caller.s thread.
@@ -2909,5 +2909,5 @@
 Below are example functions for the above Adder task, and its usage to sum up a matrix on multiple threads.
 (Note that this example is designed to display the syntax and functionality, not the best method to solve this problem)
-\begin{lstlisting}
+\begin{cfa}
 void ?{}(Adder &a, int r[], int s, int &st) { // constructor
 	a.row = r;
@@ -2946,5 +2946,5 @@
 	printf(.total is %d\n., total);
 }
-\end{lstlisting}
+\end{cfa}
 
 
@@ -2959,5 +2959,5 @@
 Similarly, when a task tries to push something onto the list, but it is full, it will yield until another task frees some space with the pop function.
 
-\begin{lstlisting}
+\begin{cfa}
 // type T is used as a generic type for all definitions inside
 // the curly brackets
@@ -2984,5 +2984,5 @@
 	}
 }
-\end{lstlisting}
+\end{cfa}
 
 A task can also yield indefinitely by calling yield with no arguments.
@@ -2991,5 +2991,5 @@
 The code below shows a simple ping-pong example, where two tasks yield back and forth to each other using these methods.
 
-\begin{lstlisting}
+\begin{cfa}
 type Ping = task {
 	Pong *partner;
@@ -3029,8 +3029,8 @@
 	Ping{pong}; // initialize and start ping
 }
-\end{lstlisting}
+\end{cfa}
 
 The same functionality can be accomplished by providing functions to be called by the partner task.
-\begin{lstlisting}
+\begin{cfa}
 type Pingpong = task {
 	String msg;
@@ -3060,5 +3060,5 @@
 	go(ping);
 }
-\end{lstlisting}
+\end{cfa}
 
 
@@ -3092,5 +3092,5 @@
 Within a module, all of the module's global definitions are visible throughout the module.
 For example, the following code compiles, even though ©isOdd© was not declared before being called:
-\begin{lstlisting}
+\begin{cfa}
 bool isEven(unsigned int x) {
 	if (x == 0) return true;
@@ -3102,5 +3102,5 @@
 	else return !isEven(x - 2);
 }
-\end{lstlisting}
+\end{cfa}
 
 Header files in C are used to expose the declarations from a library, so that they can be used externally.
@@ -3137,5 +3137,5 @@
 
 The following code is a simple module declaration example.
-\begin{lstlisting}
+\begin{cfa}
 module M;
 
@@ -3150,5 +3150,5 @@
 
 double bCounter;
-\end{lstlisting}
+\end{cfa}
 
 export module moduleName; can be use to re-export all the visible (exported) names in moduleName from the current module.
@@ -3171,5 +3171,5 @@
 The following code snippets show the two situations.
 
-\begin{lstlisting}
+\begin{cfa}
 module util/counter;
 export int f(int i) { return i+1; }
@@ -3185,10 +3185,10 @@
 	return ct.f(200); // f() from the package counter
 }
-\end{lstlisting}
+\end{cfa}
 
 
 Additionally, using the .as. syntax, a user can force the compiler to add the imported names into the current namespace using .as ..With these module rules, the following module definitions and imports can be achieved without any problem.
 
-\begin{lstlisting}
+\begin{cfa}
 module M1;
 export int f(int i) { return i+1;} // visible outside
@@ -3208,5 +3208,5 @@
 	return f(3) + g(4); //f() from M1 and g() from M2;
 }
-\end{lstlisting}
+\end{cfa}
 
 
@@ -3225,5 +3225,5 @@
 If an aggregated module is imported, all the included modules in the aggregation are imported.
 
-\begin{lstlisting}
+\begin{cfa}
 module std/sequence;
 
@@ -3237,5 +3237,5 @@
 	module std/stack;
 };
-\end{lstlisting}
+\end{cfa}
 
 After importing the aggregated module, each individual name is still contained in the original name space.
@@ -3341,5 +3341,5 @@
 
 Here is an example of a package, util.
-\begin{lstlisting}
+\begin{cfa}
 + util
 Do.prj #package description file
@@ -3357,5 +3357,5 @@
 	sequence.do #Case 4, module std/sequence;
 	test.do #Case 5
-\end{lstlisting}
+\end{cfa}
 
 \begin{itemize}
@@ -3435,5 +3435,5 @@
 Here is a simple example of the directory structure of a package, core.
 It contains a module std and several sub-modules under std.
-\begin{lstlisting}
+\begin{cfa}
 + core
 	Do.prj
@@ -3445,5 +3445,5 @@
 	vector.do #module std/container/vector;
 	list.do #module std/container/list;
-\end{lstlisting}
+\end{cfa}
 
 
@@ -3534,5 +3534,5 @@
 
 Here is an example of a package, util.
-\begin{lstlisting}
+\begin{cfa}
 + util
 	Do.prj #package description file
@@ -3550,5 +3550,5 @@
 	sequence.do #Case 4, module std/sequence;
 	test.do #Case 5
-\end{lstlisting}
+\end{cfa}
 
 
@@ -3641,5 +3641,5 @@
 \subsubsection{Package and Module Locating Example}
 
-\begin{lstlisting}
+\begin{cfa}
 # A project's source code tree
 
@@ -3676,8 +3676,8 @@
 
 ----------------------------------------
-\end{lstlisting}
-
-
-\begin{lstlisting}
+\end{cfa}
+
+
+\begin{cfa}
 # pkg directory's source code tree
 
@@ -3700,5 +3700,5 @@
 	security.do #module security;
 ------------------------------------------
-\end{lstlisting}
+\end{cfa}
 
 
@@ -3744,5 +3744,5 @@
 \multicolumn{1}{c|}{\textbf{\CFA}}	& \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}	\\
 \hline
-\begin{lstlisting}
+\begin{cfa}
 struct Line {
 	float lnth;
@@ -3771,5 +3771,5 @@
 Line line1;
 Line line2 = { 3.4 };
-\end{lstlisting}
+\end{cfa}
 &
 \begin{lstlisting}[language=C++]
@@ -3831,5 +3831,5 @@
 \end{lstlisting}
 &
-\begin{lstlisting}
+\begin{cfa}
 struct Line {
 	length: f32
@@ -3858,5 +3858,5 @@
 let line1:Line = Default::default();
 Line line2( 3.4 );
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{flushleft}
@@ -3869,5 +3869,5 @@
 \multicolumn{1}{c|}{\textbf{\CFA}}	& \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}	\\
 \hline
-\begin{lstlisting}
+\begin{cfa}
 struct Cpx {
 	double re, im;
@@ -3879,7 +3879,7 @@
 Cpx a, b, c;
 c = a + b;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 struct Cpx {
 	double re, im;
@@ -3891,7 +3891,7 @@
 Cpx a, b, c;
 c = a + b;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 // no operator overloading
 
@@ -3902,7 +3902,7 @@
 
 
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 struct Cpx {
 	re: f32,
@@ -3921,5 +3921,5 @@
 let (a, b, mut c) = ...;
 c = a + b
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{flushleft}
@@ -3932,5 +3932,5 @@
 \multicolumn{1}{c|}{\textbf{\CFA/\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}	\\
 \hline
-\begin{lstlisting}[boxpos=t]
+\begin{cfa}[boxpos=t]
 extern "C" {
 #include <sys/types.h>
@@ -3943,7 +3943,7 @@
 	return s.st_size;
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}[boxpos=t]
+\begin{cfa}[boxpos=t]
 /*
 #cgo
@@ -3962,7 +3962,7 @@
 	return buf._st_size
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}[boxpos=t]
+\begin{cfa}[boxpos=t]
 use libc::{c_int, size_t};
 // translated from sys/stat.h
@@ -3986,5 +3986,5 @@
 	}
 }
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{flushleft}
@@ -3997,5 +3997,5 @@
 \multicolumn{1}{c|}{\textbf{\CFA}}	& \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}	\\
 \hline
-\begin{lstlisting}
+\begin{cfa}
 generic(type T, type N |
 	{ int ?<?(N, N); })
@@ -4018,7 +4018,7 @@
 	return maximize(length, n, p);
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 template<typename T, typename F>
 T *maximize(const F &f,
@@ -4043,7 +4043,7 @@
 	}, n, p);
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 // Go does not support generics!
 func maximize(
@@ -4073,7 +4073,7 @@
 	a).(string)
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 use std::cmp::Ordering;
 
@@ -4101,5 +4101,5 @@
 	maximize(|x: &String| x.len(), a)
 }
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{flushleft}
@@ -4109,5 +4109,5 @@
 \subsubsection{Modules / Packages}
 
-\begin{lstlisting}
+\begin{cfa}
 \CFA
 \CC
@@ -4185,5 +4185,5 @@
 	println!(.{}., M::inc(100));
 }
-\end{lstlisting}
+\end{cfa}
 \end{comment}
 
@@ -4195,5 +4195,5 @@
 \multicolumn{1}{c|}{\textbf{\CFA}}	& \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}	\\
 \hline
-\begin{lstlisting}
+\begin{cfa}
 task Nonzero {
 	int *data;
@@ -4236,7 +4236,7 @@
 	return res;
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 #include <thread>
 #include <mutex>
@@ -4279,7 +4279,7 @@
 	return res;
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 package main
 
@@ -4304,7 +4304,7 @@
 	fmt.Println(res)
 }
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 use std::thread;
 use std::sync:mpsc::channel;
@@ -4339,5 +4339,5 @@
 	println!(.{}., res);
 }
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{flushleft}
@@ -4436,20 +4436,20 @@
 \begin{description}
 \item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
-\begin{lstlisting}
+\begin{cfa}
 int rtn( int i );
 int rtn( char c );
 rtn( 'x' );						§\C{// programmer expects 2nd rtn to be called}§
-\end{lstlisting}
+\end{cfa}
 \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
-\begin{lstlisting}
+\begin{cfa}
 sout | 'x' | " " | (int)'x' | endl;
 x 120
-\end{lstlisting}
+\end{cfa}
 Having to cast ©'x'© to ©char© is non-intuitive.
 \item[Effect on original feature:] change to semantics of well-defined feature that depend on:
-\begin{lstlisting}
+\begin{cfa}
 sizeof( 'x' ) == sizeof( int )
-\end{lstlisting}
+\end{cfa}
 no long work the same in \CFA programs.
 \item[Difficulty of converting:] simple
@@ -4460,15 +4460,15 @@
 \begin{description}
 \item[Change:] make string literals ©const©:
-\begin{lstlisting}
+\begin{cfa}
 char * p = "abc";				§\C{// valid in C, deprecated in \CFA}§
 char * q = expr ? "abc" : "de";	§\C{// valid in C, invalid in \CFA}§
-\end{lstlisting}
+\end{cfa}
 The type of a string literal is changed from ©[] char© to ©const [] char©.
 Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.
 \item[Rationale:] This change is a safety issue:
-\begin{lstlisting}
+\begin{cfa}
 char * p = "abc";
 p[0] = 'w';						§\C{// segment fault or change constant literal}§
-\end{lstlisting}
+\end{cfa}
 The same problem occurs when passing a string literal to a routine that changes its argument.
 \item[Effect on original feature:] change to semantics of well-defined feature.
@@ -4480,17 +4480,17 @@
 \begin{description}
 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
-\begin{lstlisting}
+\begin{cfa}
 int i;							§\C{// forward definition}§
 int *j = ®&i®;					§\C{// forward reference, valid in C, invalid in \CFA}§
 int i = 0;						§\C{// definition}§
-\end{lstlisting}
+\end{cfa}
 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
 This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example,
-\begin{lstlisting}
+\begin{cfa}
 struct X { int i; struct X *next; };
 static struct X a;				§\C{// forward definition}§
 static struct X b = { 0, ®&a® };	§\C{// forward reference, valid in C, invalid in \CFA}§
 static struct X a = { 1, &b };	§\C{// definition}§
-\end{lstlisting}
+\end{cfa}
 \item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.
 \item[Effect on original feature:] change to semantics of well-defined feature.
@@ -4502,5 +4502,5 @@
 \begin{description}
 \item[Change:] have ©struct© introduce a scope for nested types:
-\begin{lstlisting}
+\begin{cfa}
 enum ®Colour® { R, G, B, Y, C, M };
 struct Person {
@@ -4516,5 +4516,5 @@
 Personß.ß®Colour® pc = Personß.ßR;	§\C{// type/enum defined inside}§
 Personß.ßFace pretty;			§\C{// type defined inside}§
-\end{lstlisting}
+\end{cfa}
 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, i.e., the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
@@ -4531,10 +4531,10 @@
 \item[Rationale:] C++ classes have member functions which require that classes establish scopes.
 \item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
-\begin{lstlisting}
+\begin{cfa}
 struct Y;						§\C{// struct Y and struct X are at the same scope}§
 struct X {
 struct Y { /* ... */ } y;
 };
-\end{lstlisting}
+\end{cfa}
 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.
@@ -4602,13 +4602,13 @@
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{\CC}}	\\
-\begin{lstlisting}
+\begin{cfa}
 int x = 0, y = 1, z = 2;
 ®sout® ®|® x ®|® y ®|® z ®| endl®;
-\end{lstlisting}
+\end{cfa}
 &
-\begin{lstlisting}
+\begin{cfa}
 
 cout << x << " " << y << " " << z << endl;
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -4621,13 +4621,13 @@
 \textbf{\CFA:}
 &
-\begin{lstlisting}
+\begin{cfa}
 sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
-\end{lstlisting}
+\end{cfa}
 \\
 \textbf{\CC:}
 &
-\begin{lstlisting}
+\begin{cfa}
 cout << x * 3 << y + 1 << (z << 2) << (x == y) << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
-\end{lstlisting}
+\end{cfa}
 \end{tabular}
 \end{quote2}
@@ -4639,93 +4639,93 @@
 \item
 A separator does not appear at the start or end of a line.
-\begin{lstlisting}[belowskip=0pt]
+\begin{cfa}[belowskip=0pt]
 sout | 1 | 2 | 3 | endl;
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 1 2 3
-\end{lstlisting}
+\end{cfa}
 \item
 A separator does not appear before or after a character literal or variable.
-\begin{lstlisting}
+\begin{cfa}
 sout | '1' | '2' | '3' | endl;
 123
-\end{lstlisting}
+\end{cfa}
 \item
 A separator does not appear before or after a null (empty) C string
-\begin{lstlisting}
+\begin{cfa}
 sout | 1 | "" | 2 | "" | 3 | endl;
 123
-\end{lstlisting}
+\end{cfa}
 which is a local mechanism to disable insertion of the separator character.
 \item
 A separator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{=$£¥¡¿«@
 %$
-\begin{lstlisting}[mathescape=off]
+\begin{cfa}[mathescape=off]
 sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥" | 7
 	 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
-\end{lstlisting}
+\end{cfa}
 %$
-\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[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 «10
-\end{lstlisting}
+\end{cfa}
 %$
 \item
 {\lstset{deletedelim=**[is][]{¢}{¢}}
 A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.:;!?)]}%¢»©
-\begin{lstlisting}[belowskip=0pt]
+\begin{cfa}[belowskip=0pt]
 sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | "% x"
 	 | 8 | "¢ x" | 9 | "» x" | 10 | ") x" | 11 | "] x" | 12 | "} x" | endl;
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 1, x 2. x 3: x 4; x 5! x 6? x 7% x 8¢ x 9» x 10) x 11] x 12} x
-\end{lstlisting}}%
+\end{cfa}}%
 \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@
-\begin{lstlisting}[belowskip=0pt]
+\begin{cfa}[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]
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
 x`1`x'2'x"3"x x 4 x x	1	x
-\end{lstlisting}
+\end{cfa}
 \end{enumerate}
 The following \CC-style \Index{manipulator}s allow further control over implicit seperation.
-\begin{lstlisting}[mathescape=off,belowskip=0pt]
+\begin{cfa}[mathescape=off,belowskip=0pt]
 sout | sepOn | 1 | 2 | 3 | sepOn | endl;	§\C{// separator at start of line}§
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
  1 2 3
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sout | 1 | sepOff | 2 | 3 | endl;			§\C{// turn off implicit separator locally}§
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 12 3
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sout | sepDisable | 1 | 2 | 3 | endl;		§\C{// turn off implicit separation globally}§
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 123
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sout | 1 | sepOn | 2 | 3 | endl;			§\C{// turn on implicit separator locally}§
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 1 23
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sout | sepEnable | 1 | 2 | 3 | endl;		§\C{// turn on implicit separation globally}§
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
  1 2 3
-\end{lstlisting}
-\begin{lstlisting}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
+\end{cfa}
+\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
 sepSet( sout, ", $" );						§\C{// change separator from " " to ", \$"}§
 sout | 1 | 2 | 3 | endl;
-\end{lstlisting}
+\end{cfa}
 %$
-\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt]
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
 1, $2, $3
-\end{lstlisting}
+\end{cfa}
 %$
 \begin{comment}
@@ -4769,5 +4769,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 forall( otype T ) T * malloc( void );§\indexc{malloc}§
 forall( otype T ) T * malloc( char fill );
@@ -4784,5 +4784,5 @@
 forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill
 forall( otype T ) T * memset( T * ptr );				// remove when default value available
-\end{lstlisting}
+\end{cfa}
 
 
@@ -4790,5 +4790,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 int ato( const char * ptr );§\indexc{ato}§
 unsigned int ato( const char * ptr );
@@ -4816,5 +4816,5 @@
 double _Complex strto( const char * sptr, char ** eptr );
 long double _Complex strto( const char * sptr, char ** eptr );
-\end{lstlisting}
+\end{cfa}
 
 
@@ -4822,5 +4822,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 forall( otype T | { int ?<?( T, T ); } )
 T * bsearch( const T key, const T * arr, size_t dimension );§\indexc{bsearch}§
@@ -4828,5 +4828,5 @@
 forall( otype T | { int ?<?( T, T ); } )
 void qsort( const T * arr, size_t dimension );§\indexc{qsort}§
-\end{lstlisting}
+\end{cfa}
 
 
@@ -4834,5 +4834,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 char abs( char );§\indexc{abs}§
 int abs( int );
@@ -4845,5 +4845,5 @@
 double abs( double _Complex );
 long double abs( long double _Complex );
-\end{lstlisting}
+\end{cfa}
 
 
@@ -4851,5 +4851,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 void rand48seed( long int s );§\indexc{rand48seed}§
 char rand48();§\indexc{rand48}§
@@ -4863,5 +4863,5 @@
 double _Complex rand48();
 long double _Complex rand48();
-\end{lstlisting}
+\end{cfa}
 
 
@@ -4869,5 +4869,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 forall( otype T | { int ?<?( T, T ); } )
 T min( const T t1, const T t2 );§\indexc{min}§
@@ -4881,5 +4881,5 @@
 forall( otype T )
 void swap( T * t1, T * t2 );§\indexc{swap}§
-\end{lstlisting}
+\end{cfa}
 
 
@@ -4893,5 +4893,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float fabs( float );§\indexc{fabs}§
 double fabs( double );
@@ -4937,5 +4937,5 @@
 double nan( const char * );
 long double nan( const char * );
-\end{lstlisting}
+\end{cfa}
 
 
@@ -4943,5 +4943,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float exp( float );§\indexc{exp}§
 double exp( double );
@@ -4994,5 +4994,5 @@
 double logb( double );
 long double logb( long double );
-\end{lstlisting}
+\end{cfa}
 
 
@@ -5000,5 +5000,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float sqrt( float );§\indexc{sqrt}§
 double sqrt( double );
@@ -5022,5 +5022,5 @@
 double _Complex pow( double _Complex, double _Complex );
 long double _Complex pow( long double _Complex, long double _Complex );
-\end{lstlisting}
+\end{cfa}
 
 
@@ -5028,5 +5028,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float sin( float );§\indexc{sin}§
 double sin( double );
@@ -5078,5 +5078,5 @@
 double atan( double, double );§\indexc{atan}§
 long double atan( long double, long double );
-\end{lstlisting}
+\end{cfa}
 
 
@@ -5084,5 +5084,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float sinh( float );§\indexc{sinh}§
 double sinh( double );
@@ -5126,5 +5126,5 @@
 double _Complex atanh( double _Complex );
 long double _Complex atanh( long double _Complex );
-\end{lstlisting}
+\end{cfa}
 
 
@@ -5132,5 +5132,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float erf( float );§\indexc{erf}§
 double erf( double );
@@ -5157,5 +5157,5 @@
 double tgamma( double );
 long double tgamma( long double );
-\end{lstlisting}
+\end{cfa}
 
 
@@ -5163,5 +5163,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float floor( float );§\indexc{floor}§
 double floor( double );
@@ -5211,5 +5211,5 @@
 long long int llround( double );
 long long int llround( long double );
-\end{lstlisting}
+\end{cfa}
 
 
@@ -5217,5 +5217,5 @@
 
 \leavevmode
-\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
+\begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float copysign( float, float );§\indexc{copysign}§
 double copysign( double, double );
@@ -5252,5 +5252,5 @@
 double scalbln( double, long int );
 long double scalbln( long double, long int );
-\end{lstlisting}
+\end{cfa}
 
 
@@ -5261,5 +5261,5 @@
 When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible.
 
-\begin{lstlisting}[belowskip=0pt]
+\begin{cfa}[belowskip=0pt]
 // implementation
 struct Rational {§\indexc{Rational}§
@@ -5304,5 +5304,5 @@
 forall( dtype istype | istream( istype ) ) istype * ?|?( istype *, Rational * );
 forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype *, Rational );
-\end{lstlisting}
+\end{cfa}
 
 
