Context Navigation

-                      rbdeba0b
+                      r955d27e9
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%
+%%
 %% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo
 %%
 %% The contents of this file are covered under the licence agreement in the
 %% file "LICENCE" distributed with Cforall.
 %%
 %% user.tex --
 %%
+%%
+%% user.tex --
+%%
 %% Author           : Peter A. Buhr
 %% Created On       : Wed Apr  6 14:53:29 2016
 …
 \CFAStyle                                                                                               % use default CFA format-style
 % inline code ©...© (copyright symbol) emacs: C-q M-)
 % red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
 % blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
 % green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
 % LaTex escape §...§ (section symbol) emacs: C-q M-'
 % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
+% inline code �...� (copyright symbol) emacs: C-q M-)
+% red highlighting �...� (registered trademark symbol) emacs: C-q M-.
+% blue highlighting �...� (sharp s symbol) emacs: C-q M-_
+% green highlighting �...� (cent symbol) emacs: C-q M-"
+% LaTex escape �...� (section symbol) emacs: C-q M-'
+% keyword escape �...� (pilcrow symbol) emacs: C-q M-^
 % math escape $...$ (dollar symbol)
 …
 \multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{\CFA}}      & \multicolumn{1}{c}{\textbf{C}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
 \begin{cfa}
 #include <fstream>§\indexc{fstream}§
+#include <fstream>�\indexc{fstream}�
 int main( void ) {
         int x = 0, y = 1, z = 2;
         ®sout | x | y | z | endl;®
+        �sout | x | y | z | endl;�
+}
 \end{cfa}
+&
 \begin{lstlisting}
 #include <stdio.h>§\indexc{stdio.h}§
+#include <stdio.h>�\indexc{stdio.h}�
 int main( void ) {
         int x = 0, y = 1, z = 2;
         ®printf( "%d %d %d\n", x, y, z );®
+        �printf( "%d %d %d\n", x, y, z );�
+}
 \end{lstlisting}
+&
 \begin{lstlisting}
 #include <iostream>§\indexc{iostream}§
+#include <iostream>�\indexc{iostream}�
 using namespace std;
 int main() {
         int x = 0, y = 1, z = 2;
         ®cout<<x<<" "<<y<<" "<<z<<endl;®
+        �cout<<x<<" "<<y<<" "<<z<<endl;�
+}
 \end{lstlisting}
 …
 \CC~\cite{C++14,C++} is an example of a similar project;
 however, it largely extended the language, and did not address many existing problems.\footnote{%
 Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.}
+Two important existing problems addressed were changing the type of character literals from �int� to �char� and enumerator from �int� to the type of its enumerators.}
 \Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features (\eg objects, concurrency) are added and problems fixed within the framework of the existing language.
 \Index*{Java}~\cite{Java8}, \Index*{Go}~\cite{Go}, \Index*{Rust}~\cite{Rust} and \Index*{D}~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
 …
 (See~\cite{Werther96} for similar work in \Index*[C++]{\CC{}}.)
 A first \CFA implementation of these extensions was by Esteves~\cite{Esteves04}.
 The signature feature of \CFA is parametric-polymorphic functions~\cite{forceone:impl,Cormack90,Duggan96} with functions generalized using a ©forall© clause (giving the language its name):
+The signature feature of \CFA is parametric-polymorphic functions~\cite{forceone:impl,Cormack90,Duggan96} with functions generalized using a �forall� clause (giving the language its name):
 \begin{lstlisting}
 ®forall( otype T )® T identity( T val ) { return val; }
 int forty_two = identity( 42 );                 §\C{// T is bound to int, forty\_two == 42}§
+�forall( otype T )� T identity( T val ) { return val; }
+int forty_two = identity( 42 );                 �\C{// T is bound to int, forty\_two == 42}�
 \end{lstlisting}
 % extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC{}} approach of object-oriented extensions.
 …
 \begin{comment}
 A simple example is leveraging the existing type-unsafe (©void *©) C ©bsearch© to binary search a sorted floating-point array:
+A simple example is leveraging the existing type-unsafe (�void *�) C �bsearch� to binary search a sorted floating-point array:
 \begin{lstlisting}
 void * bsearch( const void * key, const void * base, size_t dim, size_t size,
 …
 int posn = bsearch( 5.0, vals, 10 );
 \end{lstlisting}
 The nested function ©comp© provides the hidden interface from typed \CFA to untyped (©void *©) C, plus the cast of the result.
 Providing a hidden ©comp© function in \CC is awkward as lambdas do not use C calling-conventions and template declarations cannot appear at block scope.
+The nested function �comp� provides the hidden interface from typed \CFA to untyped (�void *�) C, plus the cast of the result.
+Providing a hidden �comp� function in \CC is awkward as lambdas do not use C calling-conventions and template declarations cannot appear at block scope.
 As well, an alternate kind of return is made available: position versus pointer to found element.
 \CC's type-system cannot disambiguate between the two versions of ©bsearch© because it does not use the return type in overload resolution, nor can \CC separately compile a templated ©bsearch©.
+\CC's type-system cannot disambiguate between the two versions of �bsearch� because it does not use the return type in overload resolution, nor can \CC separately compile a templated �bsearch�.
 \CFA has replacement libraries condensing hundreds of existing C functions into tens of \CFA overloaded functions, all without rewriting the actual computations.
 For example, it is possible to write a type-safe \CFA wrapper ©malloc© based on the C ©malloc©:
+For example, it is possible to write a type-safe \CFA wrapper �malloc� based on the C �malloc�:
 \begin{lstlisting}
 forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
 int * ip = malloc();                                    §\C{// select type and size from left-hand side}§
+int * ip = malloc();                                    �\C{// select type and size from left-hand side}�
 double * dp = malloc();
 struct S {...} * sp = malloc();
 …
 However, it is necessary to differentiate between C and \CFA code because of name overloading, as for \CC.
 For example, the C math-library provides the following routines for computing the absolute value of the basic 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©:
+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{cfa}
 char abs( char );
+®extern "C" {®
 int abs( int );                                                 §\C{// use default C routine for int}§
 ®}® // extern "C"
+�extern "C" {�
+int abs( int );                                                 �\C{// use default C routine for int}�
+�}� // extern "C"
 long int abs( long int );
 long long int abs( long long int );
 …
 long double _Complex abs( long double _Complex );
 \end{cfa}
 The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
 Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
+The problem is the name clash between the library routine �abs� and the \CFA names �abs�.
+Hence, names appearing in an �extern "C"� block have \newterm*{C linkage}.
 Then overloading polymorphism uses a mechanism called \newterm{name mangling}\index{mangling!name} to create unique names that are different from C names, which are not mangled.
 Hence, there is the same need as in \CC, to know if a name is a C or \CFA name, so it can be correctly formed.
 There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
 This example strongly illustrates a core idea in \CFA: \emph{the power of a name}.
 The name ``©abs©'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
 Hence, knowing the name ©abs© should be sufficient to apply it to any type where it is applicable.
+The name ``�abs�'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
+Hence, knowing the name �abs� should be sufficient to apply it to any type where it is applicable.
 The time savings and safety of using one name uniformly versus $N$ unique names should not be underestimated.
 …
 \section[Compiling CFA Program]{Compiling \CFA Program}
 The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg:
 \begin{cfa}
 cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
 \end{cfa}
 \CFA programs having the following ©gcc© flags turned on:
+The command �cfa� is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg:
+\begin{cfa}
+cfa�\indexc{cfa}\index{compilation!cfa@�cfa�}� [ gcc-options ] C/�\CFA�-files [ assembler/loader-files ]
+\end{cfa}
+\CFA programs having the following �gcc� flags turned on:
 \begin{description}
 \item
 \Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
+\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{�-std=gnu99�}}
 The 1999 C standard plus GNU extensions.
 \item
 {\lstset{deletekeywords={inline}}
 \Indexc{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{©-fgnu89-inline©}}
+\Indexc{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{�-fgnu89-inline�}}
 Use the traditional GNU semantics for inline routines in C99 mode, which allows inline routines in header files.
 }%
 …
 \begin{description}
 \item
 \Indexc{-CFA}\index{compilation option!-CFA@©-CFA©}
+\Indexc{-CFA}\index{compilation option!-CFA@�-CFA�}
 Only the C preprocessor and the \CFA translator steps are performed and the transformed program is written to standard output, which makes it possible to examine the code generated by the \CFA translator.
 The generated code started with the standard \CFA prelude.
 \item
 \Indexc{-debug}\index{compilation option!-debug@©-debug©}
+\Indexc{-debug}\index{compilation option!-debug@�-debug�}
 The program is linked with the debugging version of the runtime system.
 The debug version performs runtime checks to help during the debugging phase of a \CFA program, but substantially slows the execution of the program.
 …
 \item
 \Indexc{-nodebug}\index{compilation option!-nodebug@©-nodebug©}
+\Indexc{-nodebug}\index{compilation option!-nodebug@�-nodebug�}
 The program is linked with the non-debugging version of the runtime system, so the execution of the program is faster.
 \Emph{However, no runtime checks or ©assert©s are performed so errors usually result in abnormal program termination.}
 \item
 \Indexc{-help}\index{compilation option!-help@©-help©}
+\Emph{However, no runtime checks or �assert�s are performed so errors usually result in abnormal program termination.}
+\item
+\Indexc{-help}\index{compilation option!-help@�-help�}
 Information about the set of \CFA compilation flags is printed.
 \item
 \Indexc{-nohelp}\index{compilation option!-nohelp@©-nohelp©}
+\Indexc{-nohelp}\index{compilation option!-nohelp@�-nohelp�}
 Information about the set of \CFA compilation flags is not printed.
 \textbf{This option is the default.}
 \item
 \Indexc{-quiet}\index{compilation option!-quiet@©-quiet©}
+\Indexc{-quiet}\index{compilation option!-quiet@�-quiet�}
 The \CFA compilation message is not printed at the beginning of a compilation.
 \item
 \Indexc{-noquiet}\index{compilation option!-noquiet@©-noquiet©}
+\Indexc{-noquiet}\index{compilation option!-noquiet@�-noquiet�}
 The \CFA compilation message is printed at the beginning of a compilation.
 \textbf{This option is the default.}
 \item
 \Indexc{-no-include-stdhdr}\index{compilation option!-no-include-stdhdr@©-no-include-stdhdr©}
 Do not supply ©extern "C"© wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}).
+\Indexc{-no-include-stdhdr}\index{compilation option!-no-include-stdhdr@�-no-include-stdhdr�}
+Do not supply �extern "C"� wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}).
 \textbf{This option is \emph{not} the default.}
 \end{description}
 …
 \begin{description}
 \item
 \Indexc{__CFA_MAJOR__}\index{preprocessor variables!__CFA__@{©__CFA__©}}
+\Indexc{__CFA_MAJOR__}\index{preprocessor variables!__CFA__@{�__CFA__�}}
 is available during preprocessing and its value is the major \Index{version number} of \CFA.\footnote{
 The C preprocessor allows only integer values in a preprocessor variable so a value like ``\Version'' is not allowed.
 …
 \item
 \Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{©__CFA_MINOR__©}}
+\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{�__CFA_MINOR__�}}
 is available during preprocessing and its value is the minor \Index{version number} of \CFA.
 \item
 \Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@©__CFA_PATCH__©}
+\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@�__CFA_PATCH__�}
 is available during preprocessing and its value is the patch \Index{level number} of \CFA.
 \item
 \Indexc{__CFA__}\index{preprocessor variables!__CFA__@©__CFA__©},
 \Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@©__CFORALL__©} and
 \Indexc{__cforall}\index{preprocessor variables!__cforall@©__cforall©}
+\Indexc{__CFA__}\index{preprocessor variables!__CFA__@�__CFA__�},
+\Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@�__CFORALL__�} and
+\Indexc{__cforall}\index{preprocessor variables!__cforall@�__cforall�}
 are always available during preprocessing and have no value.
 \end{description}
 …
 \begin{cfa}
 #ifndef __CFORALL__
 #include <stdio.h>§\indexc{stdio.h}§    §\C{// C header file}§
+#include <stdio.h>�\indexc{stdio.h}�    �\C{// C header file}�
 #else
 #include <fstream>§\indexc{fstream}§    §\C{// \CFA header file}§
+#include <fstream>�\indexc{fstream}�    �\C{// \CFA header file}�
 #endif
 \end{cfa}
 which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}.
+which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}.
 …
 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg:
 \begin{cfa}
 ®_®147®_®483®_®648;                                    §\C{// decimal constant}§
 ®_®ul;                                                                §\C{// decimal unsigned long constant}§
 ®_®377;                                                                §\C{// octal constant}§
 x®_®ff®_®ff;                                                   §\C{// hexadecimal constant}§
 x®_®ef3d®_®aa5c;                                               §\C{// hexadecimal constant}§
 .141®_®592®_®654;                                              §\C{// floating point constant}§
 ®_®e®_®+1®_®00;                                               §\C{// floating point constant}§
 x®_®ff®_®ff®_®p®_®3;                                   §\C{// hexadecimal floating point}§
 x®_®1.ffff®_®ffff®_®p®_®128®_®l;               §\C{// hexadecimal floating point long constant}§
 L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§;     §\C{// wide character constant}§
+�_�147�_�483�_�648;                                    �\C{// decimal constant}�
+�_�ul;                                                                �\C{// decimal unsigned long constant}�
+�_�377;                                                                �\C{// octal constant}�
+x�_�ff�_�ff;                                                   �\C{// hexadecimal constant}�
+x�_�ef3d�_�aa5c;                                               �\C{// hexadecimal constant}�
+.141�_�592�_�654;                                              �\C{// floating point constant}�
+�_�e�_�+1�_�00;                                               �\C{// floating point constant}�
+x�_�ff�_�ff�_�p�_�3;                                   �\C{// hexadecimal floating point}�
+x�_�1.ffff�_�ffff�_�p�_�128�_�l;               �\C{// hexadecimal floating point long constant}�
+L�_��"\texttt{\textbackslash{x}}��_��\texttt{ff}��_��\texttt{ee}"�;     �\C{// wide character constant}�
 \end{cfa}
 The rules for placement of underscores is as follows:
 \begin{enumerate}
 \item
 A sequence of underscores is disallowed, \eg ©12__34© is invalid.
+A sequence of underscores is disallowed, \eg �12__34� is invalid.
 \item
 Underscores may only appear within a sequence of digits (regardless of the digit radix).
 In other words, an underscore cannot start or end a sequence of digits, \eg ©_1©, ©1_© and ©_1_© are invalid (actually, the 1st and 3rd examples are identifier names).
+In other words, an underscore cannot start or end a sequence of digits, \eg �_1�, �1_� and �_1_� are invalid (actually, the 1st and 3rd examples are identifier names).
 \item
 A numeric prefix may end with an underscore;
 a numeric infix may begin and/or end with an underscore;
 a numeric suffix may begin with an underscore.
 For example, the octal ©0© or hexadecimal ©0x© prefix may end with an underscore ©0_377© or ©0x_ff©;
 the exponent infix ©E© may start or end with an underscore ©1.0_E10©, ©1.0E_10© or ©1.0_E_10©;
 the type suffixes ©U©, ©L©, etc. may start with an underscore ©1_U©, ©1_ll© or ©1.0E10_f©.
+For example, the octal �0� or hexadecimal �0x� prefix may end with an underscore �0_377� or �0x_ff�;
+the exponent infix �E� may start or end with an underscore �1.0_E10�, �1.0E_10� or �1.0_E_10�;
+the type suffixes �U�, �L�, etc. may start with an underscore �1_U�, �1_ll� or �1.0E10_f�.
 \end{enumerate}
 It is significantly easier to read and enter long constants when they are broken up into smaller groupings (many cultures use comma and/or period among digits for the same purpose).
 …
 \CFA accommodates keyword clashes with existing C variable-names by syntactic transformations using the \CFA backquote escape-mechanism:
 \begin{cfa}
 int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
 double ®`®forall®`® = 3.5;
+int �`�otype�`� = 3;                    �\C{// make keyword an identifier}�
+double �`�forall�`� = 3.5;
 \end{cfa}
 Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
 \VRef[Figure]{f:InterpositionHeaderFile} shows how clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©:
+\VRef[Figure]{f:InterpositionHeaderFile} shows how clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: �#include_next� and �-I filename�:
 \begin{figure}
 \begin{cfa}
 // include file uses the CFA keyword "otype".
 #if ! defined( otype )                  §\C{// nesting ?}§
 #define otype ®`®otype®`®               §\C{// make keyword an identifier}§
+#if ! defined( otype )                  �\C{// nesting ?}�
+#define otype �`�otype�`�               �\C{// make keyword an identifier}�
 #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}§
+#�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__
 …
 \section{Labelled Continue/Break}
 While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
+While C provides �continue� and �break� statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
 Unfortunately, this restriction forces programmers to use \Indexc{goto} to achieve the equivalent control-flow for more than one level of nesting.
 To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@\lstinline $continue$!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@\lstinline $break$!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85,Java}.
 For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
 for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement.
 \VRef[Figure]{f:MultiLevelResumeTermination} shows the labelled ©continue© and ©break©, specifying which control structure is the target for exit, and the corresponding C program using only ©goto©.
+To prevent having to switch to the �goto�, \CFA extends the \Indexc{continue}\index{continue@\lstinline $continue$!labelled}\index{labelled!continue@�continue�} and \Indexc{break}\index{break@\lstinline $break$!labelled}\index{labelled!break@�break�} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85,Java}.
+For both �continue� and �break�, the target label must be directly associated with a �for�, �while� or �do� statement;
+for �break�, the target label can also be associated with a �switch�, �if� or compound (�{}�) statement.
+\VRef[Figure]{f:MultiLevelResumeTermination} shows the labelled �continue� and �break�, specifying which control structure is the target for exit, and the corresponding C program using only �goto�.
 The innermost loop has 7 exit points, which cause resumption or termination of one or more of the 7 \Index{nested control-structure}s.
 …
 \multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{\CFA}}      & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 ®LC:® {
         ... §declarations§ ...
         ®LS:® switch ( ... ) {
+�LC:� {
+        ... �declarations� ...
+        �LS:� switch ( ... ) {
           case 3:
                 ®LIF:® if ( ... ) {
                         ®LF:® for ( ... ) {
                                 ®LW:® while ( ... ) {
                                         ... break ®LC®; ...                     // terminate compound
                                         ... break ®LS®; ...                     // terminate switch
                                         ... break ®LIF®; ...                    // terminate if
                                         ... continue ®LF;® ...   // resume loop
                                         ... break ®LF®; ...                     // terminate loop
                                         ... continue ®LW®; ...   // resume loop
                                         ... break ®LW®; ...               // terminate loop
+                �LIF:� if ( ... ) {
+                        �LF:� for ( ... ) {
+                                �LW:� while ( ... ) {
+                                        ... break �LC�; ...                     // terminate compound
+                                        ... break �LS�; ...                     // terminate switch
+                                        ... break �LIF�; ...                    // terminate if
+                                        ... continue �LF;� ...   // resume loop
+                                        ... break �LF�; ...                     // terminate loop
+                                        ... continue �LW�; ...   // resume loop
+                                        ... break �LW�; ...               // terminate loop
                                 } // while
                         } // for
                 } else {
                         ... break ®LIF®; ...                                     // terminate if
+                        ... break �LIF�; ...                                     // terminate if
                 } // if
         } // switch
 …
 \begin{cfa}
+{
         ... §declarations§ ...
+        ... �declarations� ...
         switch ( ... ) {
           case 3:
 …
                         for ( ... ) {
                                 while ( ... ) {
                                         ... goto ®LC®; ...
                                         ... goto ®LS®; ...
                                         ... goto ®LIF®; ...
                                         ... goto ®LFC®; ...
                                         ... goto ®LFB®; ...
                                         ... goto ®LWC®; ...
                                         ... goto ®LWB®; ...
                                   ®LWC®: ; } ®LWB:® ;
                           ®LFC:® ; } ®LFB:® ;
+                                        ... goto �LC�; ...
+                                        ... goto �LS�; ...
+                                        ... goto �LIF�; ...
+                                        ... goto �LFC�; ...
+                                        ... goto �LFB�; ...
+                                        ... goto �LWC�; ...
+                                        ... goto �LWB�; ...
+                                  �LWC�: ; } �LWB:� ;
+                          �LFC:� ; } �LFB:� ;
                 } else {
                         ... goto ®LIF®; ...
                 } ®L3:® ;
         } ®LS:® ;
 } ®LC:® ;
+                        ... goto �LIF�; ...
+                } �L3:� ;
+        } �LS:� ;
+} �LC:� ;
 \end{cfa}
 \end{tabular}
 …
 Both labelled ©continue© and ©break© are a ©goto©\index{goto@\lstinline $goto$!restricted} restricted in the following ways:
+Both labelled �continue� and �break� are a �goto�\index{goto@\lstinline $goto$!restricted} restricted in the following ways:
 \begin{itemize}
 \item
 …
 This restriction prevents missing initialization at the start of a control structure resulting in undefined behaviour.
 \end{itemize}
 The advantage of the labelled ©continue©/©break© is allowing static multi-level exits without having to use the ©goto© statement, and tying control flow to the target control structure rather than an arbitrary point in a program.
+The advantage of the labelled �continue�/�break� is allowing static multi-level exits without having to use the �goto� statement, and tying control flow to the target control structure rather than an arbitrary point in a program.
 Furthermore, the location of the label at the \emph{beginning} of the target control structure informs the reader that complex control-flow is occurring in the body of the control structure.
 With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
+With �goto�, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
 Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
 The implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
+The implicit targets of the current �continue� and �break�, \ie the closest enclosing loop or �switch�, change as certain constructs are added or removed.
 \section{Switch Statement}
 C allows a number of questionable forms for the ©switch© statement:
+C allows a number of questionable forms for the �switch� statement:
 \begin{enumerate}
 \item
 By default, the end of a ©case© clause\footnote{
 In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
 \emph{falls through} to the next ©case© clause in the ©switch© statement;
 to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
+By default, the end of a �case� clause\footnote{
+In this section, the term \emph{case clause} refers to either a �case� or �default� clause.}
+\emph{falls through} to the next �case� clause in the �switch� statement;
+to exit a �switch� statement from a �case� clause requires explicitly terminating the clause with a transfer statement, most commonly �break�:
 \begin{cfa}
 switch ( i ) {
 …
 if ( argc == 3 ) {
         // open output file
         ®// open input file
 ®} else if ( argc == 2 ) {
         ®// open input file
 ®} else {
+        �// open input file
+�} else if ( argc == 2 ) {
+        �// open input file
+�} else {
         // usage message
+}
 …
 \end{quote2}
 In this example, case 2 is always done if case 3 is done.
 This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
+This control flow is difficult to simulate with if statements or a �switch� statement without fall-through as code must be duplicated or placed in a separate routine.
 C also uses fall-through to handle multiple case-values resulting in the same action:
 \begin{cfa}
 …
 \end{cfa}
 However, this situation is handled in other languages without fall-through by allowing a list of case values.
 While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
 Hence, default fall-through semantics results in a large number of programming errors as programmers often forget the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
 \item
 It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
+While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a �switch� statement.
+Hence, default fall-through semantics results in a large number of programming errors as programmers often forget the �break� statement at the end of a �case� clause, resulting in inadvertent fall-through.
+\item
+It is possible to place �case� clauses on statements nested \emph{within} the body of the �switch� statement:
 \begin{cfa}
 switch ( i ) {
 …
         if ( j < k ) {
                 ...
           ®case 1:®             // transfer into "if" statement
+          �case 1:�             // transfer into "if" statement
                 ...
         } // if
 …
         while ( j < 5 ) {
                 ...
           ®case 3:®             // transfer into "while" statement
+          �case 3:�             // transfer into "while" statement
                 ...
         } // while
 …
+}
 \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.
+which unrolls a loop N times (N = 8 above) and uses the �switch� statement to deal with any iterations not a multiple of N.
 While efficient, this sort of special purpose usage is questionable:
 \begin{quote}
 …
 \end{quote}
 \item
 It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
 Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
 The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
 hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
 This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
 \item
 It is possible to place unreachable code at the start of a ©switch© statement, as in:
+It is possible to place the �default� clause anywhere in the list of labelled clauses for a �switch� statement, rather than only at the end.
+Virtually all programming languages with a �switch� statement require the �default� clause to appear last in the case-clause list.
+The logic for this semantics is that after checking all the �case� clauses without success, the �default� clause is selected;
+hence, physically placing the �default� clause at the end of the �case� clause list matches with this semantics.
+This physical placement can be compared to the physical placement of an �else� clause at the end of a series of connected �if�/�else� statements.
+\item
+It is possible to place unreachable code at the start of a �switch� statement, as in:
 \begin{cfa}
 switch ( x ) {
         ®int y = 1;®                            §\C{// unreachable initialization}§
         ®x = 7;®                                        §\C{// unreachable code without label/branch}§
+        �int y = 1;�                            �\C{// unreachable initialization}�
+        �x = 7;�                                        �\C{// unreachable code without label/branch}�
   case 3: ...
         ...
         ®int z = 0;®                            §\C{// unreachable initialization, cannot appear after case}§
+        �int z = 0;�                            �\C{// unreachable initialization, cannot appear after case}�
         z = 2;
   case 3:
         ®x = z;®                                        §\C{// without fall through, z is uninitialized}§
+}
 \end{cfa}
 While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
 As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
 The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
+        �x = z;�                                        �\C{// without fall through, z is uninitialized}�
+}
+\end{cfa}
+While the declaration of the local variable �y� is useful with a scope across all �case� clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
+Furthermore, any statements before the first �case� clause can only be executed if labelled and transferred to using a �goto�, either from outside or inside of the �switch�, both of which are problematic.
+As well, the declaration of �z� cannot occur after the �case� because a label can only be attached to a statement, and without a fall through to case 3, �z� is uninitialized.
+The key observation is that the �switch� statement branches into control structure, \ie there are multiple entry points into its statement body.
 \end{enumerate}
 …
 \begin{itemize}
 \item
 the number of ©switch© statements is small,
 \item
 most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
 \item
 the ©default© clause is usually written as the last case-clause,
 \item
 and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
+the number of �switch� statements is small,
+\item
+most �switch� statements are well formed (\ie no \Index*{Duff's device}),
+\item
+the �default� clause is usually written as the last case-clause,
+\item
+and there is only a medium amount of fall-through from one �case� clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
 \end{itemize}
 These observations help to put the \CFA changes to the ©switch© into perspective.
+These observations help to put the \CFA changes to the �switch� into perspective.
 \begin{enumerate}
 \item
 Eliminating default fall-through has the greatest potential for affecting existing code.
 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
+However, even if fall-through is removed, most �switch� statements would continue to work because of the explicit transfers already present at the end of each �case� clause, the common placement of the �default� clause at the end of the case list, and the most common use of fall-through, \ie a list of �case� clauses executing common code, \eg:
 \begin{cfa}
 case 1:  case 2:  case 3: ...
 …
 still works.
 Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, \eg:
 \begin{cfa}
 ®choose® ( i ) {
+Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of �switch� statement, called �choose�, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword �fallthrough�/�fallthru�, \eg:
+\begin{cfa}
+�choose� ( i ) {
   case 1:  case 2:  case 3:
         ...
         ®// implicit end of switch (break)
   ®case 5:
+        �// implicit end of switch (break)
+  �case 5:
         ...
         ®fallthru®;                                     §\C{// explicit fall through}§
+        �fallthru�;                                     �\C{// explicit fall through}�
   case 7:
         ...
         ®break®                                         §\C{// explicit end of switch}§
+        �break�                                         �\C{// explicit end of switch}�
   default:
         j = 3;
+}
 \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.
 The explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
 As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
 \item
 \Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
 Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
 \item
 The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end.
+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.
+The explicit �fallthru� is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the �choose� statement.
+As well, allowing an explicit �break� from the �choose� is a carry over from the �switch� statement, and expected by C programmers.
+\item
+\Index*{Duff's device} is eliminated from both �switch� and �choose� statements, and only invalidates a small amount of very questionable code.
+Hence, the �case� clause must appear at the same nesting level as the �switch�/�choose� body, as is done in most other programming languages with �switch� statements.
+\item
+The issue of �default� at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the �default� clause needs to appear is locations other than at the end.
 Therefore, no change is made for this issue.
 \item
 Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{
 Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
+Dealing with unreachable code in a �switch�/�choose� body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate �case� clause\footnote{
+Essentially, these declarations are hoisted before the �switch�/�choose� statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first �case� clause.
 Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
 \begin{cfa}
 switch ( x ) {
         ®int i = 0;®                            §\C{// allowed only at start}§
+        �int i = 0;�                            �\C{// allowed only at start}�
   case 0:
         ...
         ®int j = 0;®                            §\C{// disallowed}§
+        �int j = 0;�                            �\C{// disallowed}�
   case 1:
+        {
                 ®int k = 0;®                    §\C{// allowed at different nesting levels}§
+                �int k = 0;�                    �\C{// allowed at different nesting levels}�
                 ...
+        }
 …
 \section{Case Clause}
 C restricts the ©case© clause of a ©switch© statement to a single value.
 For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
 Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
 Therefore, the ©case© clause is extended with a list of values, as in:
+C restricts the �case� clause of a �switch� statement to a single value.
+For multiple �case� clauses associated with the same statement, it is necessary to have multiple �case� clauses rather than multiple values.
+Requiring a �case� clause for each value does not seem to be in the spirit of brevity normally associated with C.
+Therefore, the �case� clause is extended with a list of values, as in:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
 …
 \begin{cfa}
 switch ( i ) {
   case ®1, 3, 5®:
+  case �1, 3, 5�:
         ...
   case ®2, 4, 6®:
+  case �2, 4, 6�:
         ...
+}
 …
 \begin{cfa}
 switch ( i ) {
   case ®1~5:®
+  case �1~5:�
         ...
   case ®10~15:®
+  case �10~15:�
         ...
+}
 …
 \begin{cfa}
 switch ( i )
   case ®1 ... 5®:
+  case �1 ... 5�:
         ...
   case ®10 ... 15®:
+  case �10 ... 15�:
         ...
+}
 …
 Lists of subranges are also allowed.
 \begin{cfa}
 case ®1~5, 12~21, 35~42®:
+case �1~5, 12~21, 35~42�:
 \end{cfa}
 …
 catch( Arithmetic )
 \end{cfa}
 matches all three derived exception-types: ©DivideByZero©, ©Overflow©, and ©Underflow©.
+matches all three derived exception-types: �DivideByZero�, �Overflow�, and �Underflow�.
 Because the propagation mechanisms perform a simple linear search of the handler clause for a guarded block, and selects the first matching handler, the order of catch clauses in the handler clause becomes important, \eg:
 \begin{cfa}
 …
 For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
 \begin{cfa}
 int ®(*®f®())[®5®]® {...};                              §\C{definition}§
  ... ®(*®f®())[®3®]® += 1;                              §\C{usage}§
+int �(*�f�())[�5�]� {...};                              �\C{definition}�
+ ... �(*�f�())[�3�]� += 1;                              �\C{usage}�
 \end{cfa}
 Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
 …
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 ß[5] *ß ®int® x1;
 ß* [5]ß ®int® x2;
 ß[* [5] int]ß f®( int p )®;
+�[5] *� �int� x1;
+�* [5]� �int� x2;
+�[* [5] int]� f�( int p )�;
 \end{cfa}
+&
 \begin{cfa}
 ®int® ß*ß x1 ß[5]ß;
 ®int® ß(*ßx2ß)[5]ß;
 ßint (*ßf®( int p )®ß)[5]ß;
+�int� �*� x1 �[5]�;
+�int� �(*�x2�)[5]�;
+�int (*�f�( int p )��)[5]�;
 \end{cfa}
 \end{tabular}
 \end{quote2}
 The only exception is \Index{bit field} specification, which always appear to the right of the base type.
 % Specifically, the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array or function return value, and parentheses ©()© are used to indicate a routine parameter.
+% Specifically, the character �*� is used to indicate a pointer, square brackets �[�\,�]� are used to represent an array or function return value, and parentheses �()� are used to indicate a routine parameter.
 However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
 For instance, variables ©x© and ©y© of type \Index{pointer} to integer are defined in \CFA as follows:
+For instance, variables �x� and �y� of type \Index{pointer} to integer are defined in \CFA as follows:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 ®*® int x, y;
+�*� int x, y;
 \end{cfa}
+&
 \begin{cfa}
 int ®*®x, ®*®y;
+int �*�x, �*�y;
 \end{cfa}
 \end{tabular}
 …
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 ®*® int x;
+�*� int x;
 int y;
 \end{cfa}
+&
 \begin{cfa}
 int ®*®x, y;
+int �*�x, y;
 \end{cfa}
 …
 \end{quote2}
 All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg:
+All type qualifiers, \eg �const�, �volatile�, etc., are used in the normal way with the new declarations and also appear left to right, \eg:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
 …
 \end{tabular}
 \end{quote2}
 All declaration qualifiers, \eg ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
+All declaration qualifiers, \eg �extern�, �static�, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} \eg:
 \begin{quote2}
 …
 \end{quote2}
 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:
+The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine �sizeof�:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 y = (®* int®)x;
 i = sizeof(®[ 5 ] * int®);
+y = (�* int�)x;
+i = sizeof(�[ 5 ] * int�);
 \end{cfa}
+&
 \begin{cfa}
 y = (®int *®)x;
 i = sizeof(®int * [ 5 ]®);
+y = (�int *�)x;
+i = sizeof(�int * [ 5 ]�);
 \end{cfa}
 \end{tabular}
 …
 These types may be derived from an object or routine type, called the \newterm{referenced type}.
 Objects of these types contain an \newterm{address}, which is normally a location in memory, but may also address memory-mapped registers in hardware devices.
 An integer constant expression with the value 0, or such an expression cast to type ©void *©, is called a \newterm{null-pointer constant}.\footnote{
+An integer constant expression with the value 0, or such an expression cast to type �void *�, is called a \newterm{null-pointer constant}.\footnote{
 One way to conceptualize the null pointer is that no variable is placed at this address, so the null-pointer address can be used to denote an uninitialized pointer/reference object;
 \ie the null pointer is guaranteed to compare unequal to a pointer to any object or routine.}
 …
+&
 \begin{cfa}
 int * ®const® x = (int *)100
+int * �const� x = (int *)100
 *x = 3;                 // implicit dereference
 int * ®const® y = (int *)104;
+int * �const� y = (int *)104;
 *y = *x;                // implicit dereference
 \end{cfa}
 …
 where the right example is how the compiler logically interprets the variables in the left example.
 Since a variable name only points to one address during its lifetime, it is an \Index{immutable} \Index{pointer};
 hence, the implicit type of pointer variables ©x© and ©y© are constant pointers in the compiler interpretation.
+hence, the implicit type of pointer variables �x� and �y� are constant pointers in the compiler interpretation.
 In general, variable addresses are stored in instructions instead of loaded from memory, and hence may not occupy storage.
 These approaches are contrasted in the following:
 …
 \end{quote2}
 Finally, the immutable nature of a variable's address and the fact that there is no storage for the variable pointer means pointer assignment\index{pointer!assignment}\index{assignment!pointer} is impossible.
 Therefore, the expression ©x = y© has only one meaning, ©*x = *y©, \ie manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of \Index{instruction decoding}.
+Therefore, the expression �x = y� has only one meaning, �*x = *y�, \ie manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of \Index{instruction decoding}.
 A \Index{pointer}/\Index{reference} object is a generalization of an object variable-name, \ie a mutable address that can point to more than one memory location during its lifetime.
 …
 \begin{tabular}{@{}l@{\hspace{2em}}l@{}}
 \begin{cfa}
 int x, y, ®*® p1, ®*® p2, ®**® p3;
 p1 = ®&®x;               // p1 points to x
+int x, y, �*� p1, �*� p2, �**� p3;
+p1 = �&�x;               // p1 points to x
 p2 = p1;                 // p2 points to x
 p1 = ®&®y;               // p1 points to y
+p1 = �&�y;               // p1 points to y
 p3 = &p2;               // p3 points to p2
 \end{cfa}
 …
 For example, \Index*{Algol68}~\cite{Algol68} infers pointer dereferencing to select the best meaning for each pointer usage
 \begin{cfa}
 p2 = p1 + x;                                    §\C{// compiler infers *p2 = *p1 + x;}§
 \end{cfa}
 Algol68 infers the following dereferencing ©*p2 = *p1 + x©, because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
 Unfortunately, automatic dereferencing does not work in all cases, and so some mechanism is necessary to fix incorrect choices.
+p2 = p1 + x;                                    �\C{// compiler infers *p2 = *p1 + x;}�
+\end{cfa}
+Algol68 infers the following dereferencing �*p2 = *p1 + x�, because adding the arbitrary integer value in �x� to the address of �p1� and storing the resulting address into �p2� is an unlikely operation.
+Unfortunately, automatic dereferencing does not work in all cases, and so some mechanism is necessary to fix incorrect choices.
 Rather than inferring dereference, most programming languages pick one implicit dereferencing semantics, and the programmer explicitly indicates the other to resolve address-duality.
 In C, objects of pointer type always manipulate the pointer object's address:
 \begin{cfa}
 p1 = p2;                                                §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§
 p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}§
 \end{cfa}
 even though the assignment to ©p2© is likely incorrect, and the programmer probably meant:
 \begin{cfa}
 p1 = p2;                                                §\C{// pointer address assignment}§
+®*®p2 = ®*®p1 + x;                              §\C{// pointed-to value assignment / operation}§
 \end{cfa}
 The C semantics work well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
+p1 = p2;                                                �\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}�
+p2 = p1 + x;                                    �\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}�
+\end{cfa}
+even though the assignment to �p2� is likely incorrect, and the programmer probably meant:
+\begin{cfa}
+p1 = p2;                                                �\C{// pointer address assignment}�
+�*�p2 = �*�p1 + x;                              �\C{// pointed-to value assignment / operation}�
+\end{cfa}
+The C semantics work well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (�malloc�/�free�).
 However, in most other situations, the pointed-to value is requested more often than the pointer address.
 …
 \end{cfa}
 To support this common case, a reference type is introduced in \CFA, denoted by ©&©, which is the opposite dereference semantics to a pointer type, making the value at the pointed-to location the implicit semantics for dereferencing (similar but not the same as \CC \Index{reference type}s).
 \begin{cfa}
 int x, y, ®&® r1, ®&® r2, ®&&® r3;
+®&®r1 = &x;                                             §\C{// r1 points to x}§
+®&®r2 = &r1;                                    §\C{// r2 points to x}§
+®&®r1 = &y;                                             §\C{// r1 points to y}§
+®&&®r3 = ®&®&r2;                                §\C{// r3 points to r2}§
 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§
+To support this common case, a reference type is introduced in \CFA, denoted by �&�, which is the opposite dereference semantics to a pointer type, making the value at the pointed-to location the implicit semantics for dereferencing (similar but not the same as \CC \Index{reference type}s).
+\begin{cfa}
+int x, y, �&� r1, �&� r2, �&&� r3;
+�&�r1 = &x;                                             �\C{// r1 points to x}�
+�&�r2 = &r1;                                    �\C{// r2 points to x}�
+�&�r1 = &y;                                             �\C{// r1 points to y}�
+�&&�r3 = �&�&r2;                                �\C{// r3 points to r2}�
+r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); �\C{// implicit dereferencing}�
 \end{cfa}
 Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
 …
 One way to conceptualize a reference is via a rewrite rule, where the compiler inserts a dereference operator before the reference variable for each reference qualifier in a declaration, so the previous example becomes:
 \begin{cfa}
 ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
 \end{cfa}
 When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.
+�*�r2 = ((�*�r1 + �*�r2) �*� (�**�r3 - �*�r1)) / (�**�r3 - 15);
+\end{cfa}
+When a reference operation appears beside a dereference operation, \eg �&*�, they cancel out.
 However, in C, the cancellation always yields a value (\Index{rvalue}).\footnote{
 The unary ©&© operator yields the address of its operand.
+The unary �&� operator yields the address of its operand.
 If the operand has type ``type'', the result has type ``pointer to type''.
 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}}
+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}}
 For a \CFA reference type, the cancellation on the left-hand side of assignment leaves the reference as an address (\Index{lvalue}):
 \begin{cfa}
 (&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}§
+(&�*�)r1 = &x;                                  �\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}�
 \end{cfa}
 Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
 \begin{cfa}
 (&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}§
+(&(&�*�)�*�)r3 = &(&�*�)r2;             �\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}�
 \end{cfa}
 Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth.
 …
 int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
                  &r1 = x,    &&r2 = r1,   &&&r3 = r2;
 ***p3 = 3;                                              §\C{// change x}§
 r3 = 3;                                                 §\C{// change x, ***r3}§
 **p3 = ...;                                             §\C{// change p1}§
 &r3 = ...;                                              §\C{// change r1, (\&*)**r3, 1 cancellation}§
 *p3 = ...;                                              §\C{// change p2}§
 &&r3 = ...;                                             §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§
 &&&r3 = p3;                                             §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
+***p3 = 3;                                              �\C{// change x}�
+r3 = 3;                                                 �\C{// change x, ***r3}�
+**p3 = ...;                                             �\C{// change p1}�
+&r3 = ...;                                              �\C{// change r1, (\&*)**r3, 1 cancellation}�
+*p3 = ...;                                              �\C{// change p2}�
+&&r3 = ...;                                             �\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}�
+&&&r3 = p3;                                             �\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}�
 \end{cfa}
 Furthermore, both types are equally performant, as the same amount of dereferencing occurs for both types.
 …
 As for a pointer type, a reference type may have qualifiers:
 \begin{cfa}
 const int cx = 5;                                       §\C{// cannot change cx;}§
 const int & cr = cx;                            §\C{// cannot change what cr points to}§
+®&®cr = &cx;                                            §\C{// can change cr}§
 cr = 7;                                                         §\C{// error, cannot change cx}§
 int & const rc = x;                                     §\C{// must be initialized}§
+®&®rc = &x;                                                     §\C{// error, cannot change rc}§
 const int & const crc = cx;                     §\C{// must be initialized}§
 crc = 7;                                                        §\C{// error, cannot change cx}§
+®&®crc = &cx;                                           §\C{// error, cannot change crc}§
 \end{cfa}
 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced\index{coercion} into the reference}:
 \begin{cfa}
 int & const cr = *0;                            §\C{// where 0 is the int * zero}§
+const int cx = 5;                                       �\C{// cannot change cx;}�
+const int & cr = cx;                            �\C{// cannot change what cr points to}�
+�&�cr = &cx;                                            �\C{// can change cr}�
+cr = 7;                                                         �\C{// error, cannot change cx}�
+int & const rc = x;                                     �\C{// must be initialized}�
+�&�rc = &x;                                                     �\C{// error, cannot change rc}�
+const int & const crc = cx;                     �\C{// must be initialized}�
+crc = 7;                                                        �\C{// error, cannot change cx}�
+�&�crc = &cx;                                           �\C{// error, cannot change crc}�
+\end{cfa}
+Hence, for type �& const�, there is no pointer assignment, so �&rc = &x� is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced\index{coercion} into the reference}:
+\begin{cfa}
+int & const cr = *0;                            �\C{// where 0 is the int * zero}�
 \end{cfa}
 Note, constant reference-types do not prevent \Index{addressing errors} because of explicit storage-management:
 …
 cr = 5;
 free( &cr );
 cr = 7;                                                         §\C{// unsound pointer dereference}§
 \end{cfa}
 The position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
 The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
+cr = 7;                                                         �\C{// unsound pointer dereference}�
+\end{cfa}
+The position of the �const� qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
+The �const� qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
 \CFA-style declarations (see \VRef{s:Declarations}) attempt to address this issue:
 \begin{quote2}
 …
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 ®const® * ®const® * const int ccp;
 ®const® & ®const® & const int ccr;
+�const� * �const� * const int ccp;
+�const� & �const� & const int ccr;
 \end{cfa}
+&
 \begin{cfa}
 const int * ®const® * ®const® ccp;
+const int * �const� * �const� ccp;
 \end{cfa}
 …
 Finally, like pointers, references are usable and composable with other type operators and generators.
 \begin{cfa}
 int w, x, y, z, & ar[3] = { x, y, z }; §\C{// initialize array of references}§
 &ar[1] = &w;                                            §\C{// change reference array element}§
 typeof( ar[1] ) p;                                      §\C{// (gcc) is int, i.e., the type of referenced object}§
 typeof( &ar[1] ) q;                                     §\C{// (gcc) is int \&, i.e., the type of reference}§
 sizeof( ar[1] ) == sizeof( int );       §\C{// is true, i.e., the size of referenced object}§
 sizeof( &ar[1] ) == sizeof( int *)      §\C{// is true, i.e., the size of a reference}§
 \end{cfa}
 In contrast to \CFA reference types, \Index*[C++]{\CC{}}'s reference types are all ©const© references, preventing changes to the reference address, so only value assignment is possible, which eliminates half of the \Index{address duality}.
+int w, x, y, z, & ar[3] = { x, y, z }; �\C{// initialize array of references}�
+&ar[1] = &w;                                            �\C{// change reference array element}�
+typeof( ar[1] ) p;                                      �\C{// (gcc) is int, i.e., the type of referenced object}�
+typeof( &ar[1] ) q;                                     �\C{// (gcc) is int \&, i.e., the type of reference}�
+sizeof( ar[1] ) == sizeof( int );       �\C{// is true, i.e., the size of referenced object}�
+sizeof( &ar[1] ) == sizeof( int *)      �\C{// is true, i.e., the size of a reference}�
+\end{cfa}
+In contrast to \CFA reference types, \Index*[C++]{\CC{}}'s reference types are all �const� references, preventing changes to the reference address, so only value assignment is possible, which eliminates half of the \Index{address duality}.
 Also, \CC does not allow \Index{array}s\index{array!reference} of reference\footnote{
 The reason for disallowing arrays of reference is unknown, but possibly comes from references being ethereal (like a textual macro), and hence, replaceable by the referant object.}
 …
 Therefore, for pointer/reference initialization, the initializing value must be an address not a value.
 \begin{cfa}
 int * p = &x;                                           §\C{// assign address of x}§
+®int * p = x;®                                          §\C{// assign value of x}§
 int & r = x;                                            §\C{// must have address of x}§
 \end{cfa}
 Like the previous example with C pointer-arithmetic, it is unlikely assigning the value of ©x© into a pointer is meaningful (again, a warning is usually given).
+int * p = &x;                                           �\C{// assign address of x}�
+�int * p = x;�                                          �\C{// assign value of x}�
+int & r = x;                                            �\C{// must have address of x}�
+\end{cfa}
+Like the previous example with C pointer-arithmetic, it is unlikely assigning the value of �x� into a pointer is meaningful (again, a warning is usually given).
 Therefore, for safety, this context requires an address, so it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect.
 Note, this is strictly a convenience and safety feature for a programmer.
 Hence, \CFA allows ©r© to be assigned ©x© because it infers a reference for ©x©, by implicitly inserting a address-of operator, ©&©, and it is an error to put an ©&© because the types no longer match due to the implicit dereference.
 Unfortunately, C allows ©p© to be assigned with ©&x© (address) or ©x© (value), but most compilers warn about the latter assignment as being potentially incorrect.
+Hence, \CFA allows �r� to be assigned �x� because it infers a reference for �x�, by implicitly inserting a address-of operator, �&�, and it is an error to put an �&� because the types no longer match due to the implicit dereference.
+Unfortunately, C allows �p� to be assigned with �&x� (address) or �x� (value), but most compilers warn about the latter assignment as being potentially incorrect.
 Similarly, when a reference type is used for a parameter/return type, the call-site argument does not require a reference operator for the same reason.
 \begin{cfa}
 int & f( int & r );                                     §\C{// reference parameter and return}§
 z = f( x ) + f( y );                            §\C{// reference operator added, temporaries needed for call results}§
 \end{cfa}
 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©r© can be locally reassigned within ©f©.
 Since operator routine ©?+?© 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.
+int & f( int & r );                                     �\C{// reference parameter and return}�
+z = f( x ) + f( y );                            �\C{// reference operator added, temporaries needed for call results}�
+\end{cfa}
+Within routine �f�, it is possible to change the argument by changing the corresponding parameter, and parameter �r� can be locally reassigned within �f�.
+Since operator routine �?+?� 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.
 \begin{cfa}
 int temp1 = f( x ), temp2 = f( y );
 …
 otherwise references have the same syntactic  burden as pointers in these contexts.
 When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
 \begin{cfa}
 void f( ®const® int & cr );
 void g( ®const® int * cp );
 f( 3 );                   g( ®&®3 );
 f( x + y );             g( ®&®(x + y) );
 \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 ©&© before the constant/expression for the pointer-type parameter (©g©) is a \CFA extension necessary to type match and is a common requirement before a variable in C (\eg ©scanf©).
 Importantly, ©&3© may not be equal to ©&3©, where the references occur across calls because the temporaries maybe different on each call.
+When a pointer/reference parameter has a �const� value (immutable), it is possible to pass literals and expressions.
+\begin{cfa}
+void f( �const� int & cr );
+void g( �const� int * cp );
+f( 3 );                   g( �&�3 );
+f( x + y );             g( �&�(x + y) );
+\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 �&� before the constant/expression for the pointer-type parameter (�g�) is a \CFA extension necessary to type match and is a common requirement before a variable in C (\eg �scanf�).
+Importantly, �&3� may not be equal to �&3�, where the references occur across calls because the temporaries maybe different on each call.
 \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.\footnote{
 If whole program analysis is possible, and shows the parameter is not assigned, \ie it is ©const©, the temporary is unnecessary.}
+If whole program analysis is possible, and shows the parameter is not assigned, \ie it is �const�, the temporary is unnecessary.}
 \begin{cfa}
 void f( int & r );
 void g( int * p );
 f( 3 );                   g( ®&®3 );            §\C{// compiler implicit generates temporaries}§
 f( x + y );             g( ®&®(x + y) );        §\C{// compiler implicit generates temporaries}§
+f( 3 );                   g( �&�3 );            �\C{// compiler implicit generates temporaries}�
+f( x + y );             g( �&�(x + y) );        �\C{// compiler implicit generates temporaries}�
 \end{cfa}
 Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
 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.}
+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.}
 The implicit conversion allows seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call.
 …
 \begin{cfa}
 void f( int i );
 void (*fp)( int );                                      §\C{// routine pointer}§
 fp = f;                                                         §\C{// reference initialization}§
 fp = &f;                                                        §\C{// pointer initialization}§
 fp = *f;                                                        §\C{// reference initialization}§
 fp(3);                                                          §\C{// reference invocation}§
 (*fp)(3);                                                       §\C{// pointer invocation}§
 \end{cfa}
 While C's treatment of routine objects has similarity to inferring a reference type in initialization contexts, the examples are assignment not initialization, and all possible forms of assignment are possible (©f©, ©&f©, ©*f©) without regard for type.
 Instead, a routine object should be referenced by a ©const© reference:
 \begin{cfa}
+®const® void (®&® fr)( int ) = f;       §\C{// routine reference}§
 fr = ...                                                        §\C{// error, cannot change code}§
 &fr = ...;                                                      §\C{// changing routine reference}§
 fr( 3 );                                                        §\C{// reference call to f}§
 (*fr)(3);                                                       §\C{// error, incorrect type}§
+void (*fp)( int );                                      �\C{// routine pointer}�
+fp = f;                                                         �\C{// reference initialization}�
+fp = &f;                                                        �\C{// pointer initialization}�
+fp = *f;                                                        �\C{// reference initialization}�
+fp(3);                                                          �\C{// reference invocation}�
+(*fp)(3);                                                       �\C{// pointer invocation}�
+\end{cfa}
+While C's treatment of routine objects has similarity to inferring a reference type in initialization contexts, the examples are assignment not initialization, and all possible forms of assignment are possible (�f�, �&f�, �*f�) without regard for type.
+Instead, a routine object should be referenced by a �const� reference:
+\begin{cfa}
+�const� void (�&� fr)( int ) = f;       �\C{// routine reference}�
+fr = ...                                                        �\C{// error, cannot change code}�
+&fr = ...;                                                      �\C{// changing routine reference}�
+fr( 3 );                                                        �\C{// reference call to f}�
+(*fr)(3);                                                       �\C{// error, incorrect type}�
 \end{cfa}
 because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
 …
 \subsection{Address-of Semantics}
 In C, ©&E© is an rvalue for any expression ©E©.
 \CFA extends the ©&© (address-of) operator as follows:
+In C, �&E� is an rvalue for any expression �E�.
+\CFA extends the �&� (address-of) operator as follows:
 \begin{itemize}
 \item
 if ©R© is an \Index{rvalue} of type ©T &$_1$...&$_r$© where $r \ge 1$ references (©&© symbols) than ©&R© has type ©T ®*®&$_{\color{red}2}$...&$_{\color{red}r}$©, \ie ©T© pointer with $r-1$ references (©&© symbols).
 \item
 if ©L© is an \Index{lvalue} of type ©T &$_1$...&$_l$© where $l \ge 0$ references (©&© symbols) then ©&L© has type ©T ®*®&$_{\color{red}1}$...&$_{\color{red}l}$©, \ie ©T© pointer with $l$ references (©&© symbols).
+if �R� is an \Index{rvalue} of type �T &$_1$...&$_r$� where $r \ge 1$ references (�&� symbols) than �&R� has type �T �*�&$_{\color{red}2}$...&$_{\color{red}r}$�, \ie �T� pointer with $r-1$ references (�&� symbols).
+\item
+if �L� is an \Index{lvalue} of type �T &$_1$...&$_l$� where $l \ge 0$ references (�&� symbols) then �&L� has type �T �*�&$_{\color{red}1}$...&$_{\color{red}l}$�, \ie �T� pointer with $l$ references (�&� symbols).
 \end{itemize}
 The following example shows the first rule applied to different \Index{rvalue} contexts:
 …
 \setcounter{enumi}{-1}
 \item
 lvalue to rvalue conversion: ©cv T© converts to ©T©, which allows implicit variable dereferencing.
+lvalue to rvalue conversion: �cv T� converts to �T�, which allows implicit variable dereferencing.
 \begin{cfa}
 int x;
 x + 1;                  // lvalue variable (int) converts to rvalue for expression
 \end{cfa}
 An rvalue has no type qualifiers (©cv©), so the lvalue qualifiers are dropped.
+An rvalue has no type qualifiers (�cv�), so the lvalue qualifiers are dropped.
 \end{enumerate}
 \CFA provides three new implicit conversion for reference types to simplify reference usage.
 \begin{enumerate}
 \item
 reference to rvalue conversion: ©cv T &© converts to ©T©, which allows implicit reference dereferencing.
+reference to rvalue conversion: �cv T &� converts to �T�, which allows implicit reference dereferencing.
 \begin{cfa}
 int x, &r = x, f( int p );
 x = ®r® + f( ®r® );  // lvalue reference converts to rvalue
 \end{cfa}
 An rvalue has no type qualifiers (©cv©), so the reference qualifiers are dropped.
 \item
 lvalue to reference conversion: \lstinline[deletekeywords={lvalue}]@lvalue-type cv1 T@ converts to ©cv2 T &©, which allows implicitly converting variables to references.
 \begin{cfa}
 int x, &r = ®x®, f( int & p ); // lvalue variable (int) convert to reference (int &)
 f( ®x® );               // lvalue variable (int) convert to reference (int &)
 \end{cfa}
 Conversion can restrict a type, where ©cv1© $\le$ ©cv2©, \eg passing an ©int© to a ©const volatile int &©, which has low cost.
 Conversion can expand a type, where ©cv1© $>$ ©cv2©, \eg passing a ©const volatile int© to an ©int &©, which has high cost (\Index{warning});
 furthermore, if ©cv1© has ©const© but not ©cv2©, a temporary variable is created to preserve the immutable lvalue.
 \item
 rvalue to reference conversion: ©T© converts to ©cv T &©, which allows binding references to temporaries.
+x = �r� + f( �r� );  // lvalue reference converts to rvalue
+\end{cfa}
+An rvalue has no type qualifiers (�cv�), so the reference qualifiers are dropped.
+\item
+lvalue to reference conversion: \lstinline[deletekeywords={lvalue}]@lvalue-type cv1 T@ converts to �cv2 T &�, which allows implicitly converting variables to references.
+\begin{cfa}
+int x, &r = �x�, f( int & p ); // lvalue variable (int) convert to reference (int &)
+f( �x� );               // lvalue variable (int) convert to reference (int &)
+\end{cfa}
+Conversion can restrict a type, where �cv1� $\le$ �cv2�, \eg passing an �int� to a �const volatile int &�, which has low cost.
+Conversion can expand a type, where �cv1� $>$ �cv2�, \eg passing a �const volatile int� to an �int &�, which has high cost (\Index{warning});
+furthermore, if �cv1� has �const� but not �cv2�, a temporary variable is created to preserve the immutable lvalue.
+\item
+rvalue to reference conversion: �T� converts to �cv T &�, which allows binding references to temporaries.
 \begin{cfa}
 int x, & f( int & p );
 f( ®x + 3® );   // rvalue parameter (int) implicitly converts to lvalue temporary reference (int &)
 ®&f®(...) = &x; // rvalue result (int &) implicitly converts to lvalue temporary reference (int &)
+f( �x + 3� );   // rvalue parameter (int) implicitly converts to lvalue temporary reference (int &)
+�&f�(...) = &x; // rvalue result (int &) implicitly converts to lvalue temporary reference (int &)
 \end{cfa}
 In both case, modifications to the temporary are inaccessible (\Index{warning}).
 Conversion expands the temporary-type with ©cv©, which is low cost since the temporary is inaccessible.
+Conversion expands the temporary-type with �cv�, which is low cost since the temporary is inaccessible.
 \end{enumerate}
 …
 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
 \begin{cfa}
 ®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
         §\emph{routine body}§
+}
 \end{cfa}
 where routine ©f© has three output (return values) and three input parameters.
+�[ int o1, int o2, char o3 ]� f( int i1, char i2, char i3 ) {
+        �\emph{routine body}�
+}
+\end{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.
 In detail, the brackets, ©[]©, enclose the result type, where each return value is named and that name is a local variable of the particular return type.\footnote{
+In detail, the brackets, �[]�, enclose the result type, where each return value is named and that name is a local variable of the particular return type.\footnote{
 \Index*{Michael Tiemann}, with help from \Index*{Doug Lea}, provided named return values in g++, circa 1989.}
 The value of each local return variable is automatically returned at routine termination.
 Declaration qualifiers can only appear at the start of a routine definition, \eg:
 \begin{cfa}
 ®extern® [ int x ] g( int y ) {§\,§}
+�extern� [ int x ] g( int y ) {�\,�}
 \end{cfa}
 Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified;
 in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
 \begin{cfa}
 [§\,§] g();                                                     §\C{// no input or output parameters}§
 [ void ] g( void );                                     §\C{// no input or output parameters}§
+[�\,�] g();                                                     �\C{// no input or output parameters}�
+[ void ] g( void );                                     �\C{// no input or output parameters}�
 \end{cfa}
 …
 int (*f(x))[ 5 ] int x; {}
 \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.
+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{cfa}
 typedef int foo;
 int f( int (* foo) );                           §\C{// foo is redefined as a parameter name}§
 \end{cfa}
 The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
 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.
+int f( int (* foo) );                           �\C{// foo is redefined as a parameter name}�
+\end{cfa}
+The string ``�int (* foo)�'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
+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.
 The inability to use \CFA declarations in these two contexts is probably a blessing because it precludes programmers from arbitrarily switching between declarations forms within a declaration contexts.
 C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
 \begin{cfa}
 [ int ] f( * int, int * );                      §\C{// returns an integer, accepts 2 pointers to integers}§
 [ * int, int * ] f( int );                      §\C{// returns 2 pointers to integers, accepts an integer}§
+[ int ] f( * int, int * );                      �\C{// returns an integer, accepts 2 pointers to integers}�
+[ * int, int * ] f( int );                      �\C{// returns 2 pointers to integers, accepts an integer}�
 \end{cfa}
 The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in:
 \begin{cfa}
 #define ptoa( n, d ) int (*n)[ d ]
 int f( ptoa( p, 5 ) ) ...                       §\C{// expands to int f( int (*p)[ 5 ] )}§
 [ int ] f( ptoa( p, 5 ) ) ...           §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
+int f( ptoa( p, 5 ) ) ...                       �\C{// expands to int f( int (*p)[ 5 ] )}�
+[ int ] f( ptoa( p, 5 ) ) ...           �\C{// expands to [ int ] f( int (*p)[ 5 ] )}�
 \end{cfa}
 Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
 …
 \subsection{Named Return Values}
 \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:
+\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{cfa}
 int f() {
 …
+}
 \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:
+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{cfa}
 ®[ int x, int y ]® f() {
+�[ int x, int y ]� f() {
         int z;
         ... x = 0; ... y = z; ...
         ®return;®                                                       §\C{// implicitly return x, y}§
+        �return;�                                                       �\C{// implicitly return x, y}�
+}
 \end{cfa}
 \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:
+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{cfa}
 [ int x, int y ] f() {
         ...
 }                                                                               §\C{// implicitly return x, y}§
 \end{cfa}
 In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
+}                                                                               �\C{// implicitly return x, y}�
+\end{cfa}
+In this case, the current values of �x� and �y� are returned to the calling routine just as if a �return� had been encountered.
 Named return values may be used in conjunction with named parameter values;
 …
 [ int x, int y ] f( int, x, int y ) {
         ...
 }                                                                               §\C{// implicitly return x, y}§
+}                                                                               �\C{// implicitly return x, y}�
 \end{cfa}
 This notation allows the compiler to eliminate temporary variables in nested routine calls.
 \begin{cfa}
 [ int x, int y ] f( int, x, int y );    §\C{// prototype declaration}§
+[ int x, int y ] f( int, x, int y );    �\C{// prototype declaration}�
 int a, b;
 [a, b] = f( f( f( a, b ) ) );
 \end{cfa}
 While the compiler normally ignores parameters names in prototype declarations, here they are used to eliminate temporary return-values by inferring that the results of each call are the inputs of the next call, and ultimately, the left-hand side of the assignment.
 Hence, even without the body of routine ©f© (separate compilation), it is possible to perform a global optimization across routine calls.
+Hence, even without the body of routine �f� (separate compilation), it is possible to perform a global optimization across routine calls.
 The compiler warns about naming inconsistencies between routine prototype and definition in this case, and behaviour is \Index{undefined} if the programmer is inconsistent.
 …
 as well, parameter names are optional, \eg:
 \begin{cfa}
 [ int x ] f ();                                                 §\C{// returning int with no parameters}§
 [ * int ] g (int y);                                    §\C{// returning pointer to int with int parameter}§
 [ ] h ( int, char );                                    §\C{// returning no result with int and char parameters}§
 [ * int, int ] j ( int );                               §\C{// returning pointer to int and int, with int parameter}§
+[ int x ] f ();                                                 �\C{// returning int with no parameters}�
+[ * int ] g (int y);                                    �\C{// returning pointer to int with int parameter}�
+[ ] h ( int, char );                                    �\C{// returning no result with int and char parameters}�
+[ * int, int ] j ( int );                               �\C{// returning pointer to int and int, with int parameter}�
 \end{cfa}
 This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
 …
 The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
 \begin{cfa}
 * [ int x ] () fp;                                              §\C{// pointer to routine returning int with no parameters}§
 * [ * int ] (int y) gp;                                 §\C{// pointer to routine returning pointer to int with int parameter}§
 * [ ] (int,char) hp;                                    §\C{// pointer to routine returning no result with int and char parameters}§
 * [ * int,int ] ( int ) jp;                             §\C{// pointer to routine returning pointer to int and int, with int parameter}§
+* [ int x ] () fp;                                              �\C{// pointer to routine returning int with no parameters}�
+* [ * int ] (int y) gp;                                 �\C{// pointer to routine returning pointer to int with int parameter}�
+* [ ] (int,char) hp;                                    �\C{// pointer to routine returning no result with int and char parameters}�
+* [ * int,int ] ( int ) jp;                             �\C{// pointer to routine returning pointer to int and int, with int parameter}�
 \end{cfa}
 While parameter names are optional, \emph{a routine name cannot be specified};
 for example, the following is incorrect:
 \begin{cfa}
 * [ int x ] f () fp;                                    §\C{// routine name "f" is not allowed}§
+* [ int x ] f () fp;                                    �\C{// routine name "f" is not allowed}�
 \end{cfa}
 …
 whereas a named (keyword) call may be:
 \begin{cfa}
 p( z : 3, x : 4, y : 7 );       §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§
+p( z : 3, x : 4, y : 7 );       �\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}�
 \end{cfa}
 Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters.
 …
 For example, the following routine prototypes and definition are all valid.
 \begin{cfa}
 void p( int, int, int );                        §\C{// equivalent prototypes}§
+void p( int, int, int );                        �\C{// equivalent prototypes}�
 void p( int x, int y, int z );
 void p( int y, int x, int z );
 void p( int z, int y, int x );
 void p( int q, int r, int s ) {}        §\C{// match with this definition}§
+void p( int q, int r, int s ) {}        �\C{// match with this definition}�
 \end{cfa}
 Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming.
 …
 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:
+For example, it is technically possible to disambiguate between these two overloaded definitions of �f� based on named arguments at the call site:
 \begin{cfa}
 int f( int i, int j );
 int f( int x, double y );
 f( j : 3, i : 4 );                              §\C{// 1st f}§
 f( x : 7, y : 8.1 );                    §\C{// 2nd f}§
 f( 4, 5 );                                              §\C{// ambiguous call}§
+f( j : 3, i : 4 );                              �\C{// 1st f}�
+f( x : 7, y : 8.1 );                    �\C{// 2nd f}�
+f( 4, 5 );                                              �\C{// ambiguous call}�
 \end{cfa}
 However, named arguments compound routine resolution in conjunction with conversions:
 \begin{cfa}
 f( i : 3, 5.7 );                                §\C{// ambiguous call ?}§
+f( i : 3, 5.7 );                                �\C{// ambiguous call ?}�
 \end{cfa}
 Depending on the cost associated with named arguments, this call could be resolvable or ambiguous.
 …
 the allowable positional calls are:
 \begin{cfa}
 p();                                                    §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
 p( 4 );                                                 §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
 p( 4, 4 );                                              §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
 p( 4, 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§
+p();                                                    �\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}�
+p( 4 );                                                 �\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}�
+p( 4, 4 );                                              �\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}�
+p( 4, 4, 4 );                                   �\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}�
 // empty arguments
 p(  , 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§
 p( 4,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§
 p( 4, 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
 p( 4,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
 p(  , 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§
 p(  ,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
 p(  ,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
+p(  , 4, 4 );                                   �\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}�
+p( 4,  , 4 );                                   �\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}�
+p( 4, 4,   );                                   �\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}�
+p( 4,  ,   );                                   �\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}�
+p(  , 4,   );                                   �\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}�
+p(  ,  , 4 );                                   �\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}�
+p(  ,  ,   );                                   �\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}�
 \end{cfa}
 Here the missing arguments are inserted from the default values in the parameter list.
 …
 Default values may only appear in a prototype versus definition context:
 \begin{cfa}
 void p( int x, int y = 2, int z = 3 );          §\C{// prototype: allowed}§
 void p( int, int = 2, int = 3 );                        §\C{// prototype: allowed}§
 void p( int x, int y = 2, int z = 3 ) {}        §\C{// definition: not allowed}§
+void p( int x, int y = 2, int z = 3 );          �\C{// prototype: allowed}�
+void p( int, int = 2, int = 3 );                        �\C{// prototype: allowed}�
+void p( int x, int y = 2, int z = 3 ) {}        �\C{// definition: not allowed}�
 \end{cfa}
 The reason for this restriction is to allow separate compilation.
 …
 \begin{cfa}
 p( int x, int y, int z, ... );
 p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
 p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
+p( 1, 4, 5, 6, z : 3, y : 2 ); �\C{// assume p( /* positional */, ... , /* named */ );}�
+p( 1, z : 3, y : 2, 4, 5, 6 ); �\C{// assume p( /* positional */, /* named */, ... );}�
 \end{cfa}
 In the first call, it is necessary for the programmer to conceptually rewrite the call, changing named arguments into positional, before knowing where the ellipse arguments begin.
 …
 \begin{cfa}
 void p( int x, int y = 2, int z = 3... );
 p( 1, 4, 5, 6, z : 3 );         §\C{// assume p( /* positional */, ... , /* named */ );}§
 p( 1, z : 3, 4, 5, 6 );         §\C{// assume p( /* positional */, /* named */, ... );}§
+p( 1, 4, 5, 6, z : 3 );         �\C{// assume p( /* positional */, ... , /* named */ );}�
+p( 1, z : 3, 4, 5, 6 );         �\C{// assume p( /* positional */, /* named */, ... );}�
 \end{cfa}
 The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
 …
 Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as:
 \begin{cfa}
 p( 1, /* default */, 5 );               §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§
+p( 1, /* default */, 5 );               �\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}�
 \end{cfa}
 …
 \begin{cfa}
 struct {
         int f1;                                 §\C{// named field}§
         int f2 : 4;                             §\C{// named field with bit field size}§
         int : 3;                                §\C{// unnamed field for basic type with bit field size}§
         int ;                                   §\C{// disallowed, unnamed field}§
         int *;                                  §\C{// disallowed, unnamed field}§
         int (*)( int );                 §\C{// disallowed, unnamed field}§
+        int f1;                                 �\C{// named field}�
+        int f2 : 4;                             �\C{// named field with bit field size}�
+        int : 3;                                �\C{// unnamed field for basic type with bit field size}�
+        int ;                                   �\C{// disallowed, unnamed field}�
+        int *;                                  �\C{// disallowed, unnamed field}�
+        int (*)( int );                 �\C{// disallowed, unnamed field}�
 };
 \end{cfa}
 …
 \begin{cfa}
 struct {
         int , , ;                               §\C{// 3 unnamed fields}§
+        int , , ;                               �\C{// 3 unnamed fields}�
+}
 \end{cfa}
 …
         struct T t;
 } s;
 …
 int fred() {
         s.t.c = ®S.®R;  // type qualification
         struct ®S.®T t = { ®S.®R, 1, 2 };
         enum ®S.®C c;
         union ®S.T.®U u;
+        s.t.c = �S.�R;  // type qualification
+        struct �S.�T t = { �S.�R, 1, 2 };
+        enum �S.�C c;
+        union �S.T.�U u;
+}
 \end{cfa}
 …
 \label{f:TypeNestingQualification}
 \end{figure}
 In the left example in C, types ©C©, ©U© and ©T© are implicitly hoisted outside of type ©S© into the containing block scope.
 In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``©.©'' for type qualification, as does \Index*{Java}, rather than the \CC type-selection operator ``©::©''.
+In the left example in C, types �C�, �U� and �T� are implicitly hoisted outside of type �S� into the containing block scope.
+In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``�.�'' for type qualification, as does \Index*{Java}, rather than the \CC type-selection operator ``�::�''.
 …
 const unsigned int size = 5;
 int ia[size];
 ...                                             §\C{// assign values to array ia}§
 qsort( ia, size );              §\C{// sort ascending order using builtin ?<?}§
+...                                             �\C{// assign values to array ia}�
+qsort( ia, size );              �\C{// sort ascending order using builtin ?<?}�
+{
         ®int ?<?( int x, int y ) { return x > y; }® §\C{// nested routine}§
         qsort( ia, size );      §\C{// sort descending order by local redefinition}§
+        �int ?<?( int x, int y ) { return x > y; }� �\C{// nested routine}�
+        qsort( ia, size );      �\C{// sort descending order by local redefinition}�
+}
 \end{cfa}
 …
 The following program in undefined in \CFA (and Indexc{gcc})
 \begin{cfa}
 [* [int]( int )] foo() {                §\C{// int (*foo())( int )}§
         int ®i® = 7;
+[* [int]( int )] foo() {                �\C{// int (*foo())( int )}�
+        int �i� = 7;
         int bar( int p ) {
                 ®i® += 1;                               §\C{// dependent on local variable}§
                 sout | ®i® | endl;
+                �i� += 1;                               �\C{// dependent on local variable}�
+                sout | �i� | endl;
+        }
         return bar;                                     §\C{// undefined because of local dependence}§
+        return bar;                                     �\C{// undefined because of local dependence}�
+}
 int main() {
         * [int]( int ) fp = foo();      §\C{// int (*fp)( int )}§
+        * [int]( int ) fp = foo();      �\C{// int (*fp)( int )}�
         sout | fp( 3 ) | endl;
+}
 \end{cfa}
 because
+because
 Currently, there are no \Index{lambda} expressions, \ie unnamed routines because routine names are very important to properly select the correct routine.
 …
 The general syntax of a lexical list is:
 \begin{cfa}
 [ §\emph{exprlist}§ ]
 \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.
+[ �\emph{exprlist}� ]
+\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{cfa}
 …
 [ v+w, x*y, 3.14159, f() ]
 \end{cfa}
 Tuples are permitted to contain sub-tuples (\ie nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.
+Tuples are permitted to contain sub-tuples (\ie nesting), such as �[ [ 14, 21 ], 9 ]�, which is a 2-element tuple whose first element is itself a tuple.
 Note, a tuple is not a record (structure);
 a record denotes a single value with substructure, whereas a tuple is multiple values with no substructure (see flattening coercion in Section 12.1).
 …
 The general syntax of a tuple type is:
 \begin{cfa}
 [ §\emph{typelist}§ ]
 \end{cfa}
 where ©$\emph{typelist}$© is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
+[ �\emph{typelist}� ]
+\end{cfa}
+where �$\emph{typelist}$� is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
 Examples of tuple types include:
 \begin{cfa}
 [ unsigned int, char ]
 [ double, double, double ]
 [ * int, int * ]                §\C{// mix of CFA and ANSI}§
+[ * int, int * ]                �\C{// mix of CFA and ANSI}�
 [ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ]
 \end{cfa}
 Like tuples, tuple types may be nested, such as ©[ [ int, int ], int ]©, which is a 2-element tuple type whose first element is itself a tuple type.
+Like tuples, tuple types may be nested, such as �[ [ 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{cfa}
 [ int, int ] x;                 §\C{// 2 element tuple, each element of type int}§
 * [ char, char ] y;             §\C{// pointer to a 2 element tuple}§
+[ int, int ] x;                 �\C{// 2 element tuple, each element of type int}�
+* [ char, char ] y;             �\C{// pointer to a 2 element tuple}�
 [ [ int, int ] ] z ([ int, int ]);
 \end{cfa}
 …
 tuple does not have structure like a record; a tuple is simply converted into a list of components.
 \begin{rationale}
 The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; \ie a statement such as ©g( f() )© is not supported.
+The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; \ie a statement such as �g( f() )� is not supported.
 Using a temporary variable to store the  results of the inner routine and then passing this variable to the outer routine works, however.
 \end{rationale}
 …
 \begin{rationale}
 Unfortunately, C's syntax for subscripts precluded treating them as tuples.
 The C subscript list has the form ©[i][j]...© and not ©[i, j, ...]©.
 Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, \eg ©f[g()]© always means a single subscript value because there is only one set of brackets.
 Fixing this requires a major change to C because the syntactic form ©M[i, j, k]© already has a particular meaning: ©i, j, k© is a comma expression.
+The C subscript list has the form �[i][j]...� and not �[i, j, ...]�.
+Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, \eg �f[g()]� always means a single subscript value because there is only one set of brackets.
+Fixing this requires a major change to C because the syntactic form �M[i, j, k]� already has a particular meaning: �i, j, k� is a comma expression.
 \end{rationale}
 …
 [ a, b, c, d ] = w
 \end{cfa}
 ©w© is implicitly opened to yield a tuple of four values, which are then assigned individually.
+�w� is implicitly opened to yield a tuple of four values, which are then assigned individually.
 A \newterm{flattening coercion} coerces a nested tuple, \ie 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:
 …
 First the right-hand tuple is flattened and then the values are assigned individually.
 Flattening is also performed on tuple types.
 For example, the type ©[ int, [ int, int ], int ]© can be coerced, using flattening, into the type ©[ int, int, int, int ]©.
+For example, the type �[ int, [ int, int ], int ]� can be coerced, using flattening, into the type �[ int, int, int, int ]�.
 A \newterm{structuring coercion} is the opposite of flattening;
 a tuple is structured into a more complex nested tuple.
 For example, structuring the tuple ©[ 1, 2, 3, 4 ]© into the tuple ©[ 1, [ 2, 3 ], 4 ]© or the tuple type ©[ int, int, int, int ]© into the tuple type ©[ int, [ int, int ], int ]©.
+For example, structuring the tuple �[ 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{cfa}
 [ int, int, int, int ] w = [ 1, 2, 3, 4 ];
 int x = 5;
 [ x, w ] = [ w, x ];            §\C{// all four tuple coercions}§
+[ x, w ] = [ w, x ];            �\C{// all four tuple coercions}�
 \end{cfa}
 Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values;
 therefore, the right-hand tuple is now the tuple ©[ [ 1, 2, 3, 4 ], 5 ]©.
 This tuple is then flattened, yielding ©[ 1, 2, 3, 4, 5 ]©, which is structured into ©[ 1, [ 2, 3, 4, 5 ] ]© to match the tuple type of the left-hand side.
 The tuple ©[ 2, 3, 4, 5 ]© is then closed to create a tuple value.
 Finally, ©x© is assigned ©1© and ©w© is assigned the tuple value using multiple assignment (see Section 14).
+therefore, the right-hand tuple is now the tuple �[ [ 1, 2, 3, 4 ], 5 ]�.
+This tuple is then flattened, yielding �[ 1, 2, 3, 4, 5 ]�, which is structured into �[ 1, [ 2, 3, 4, 5 ] ]� to match the tuple type of the left-hand side.
+The tuple �[ 2, 3, 4, 5 ]� is then closed to create a tuple value.
+Finally, �x� is assigned �1� and �w� is assigned the tuple value using multiple assignment (see Section 14).
 \begin{rationale}
 A possible additional language extension is to use the structuring coercion for tuples to initialize a complex record with a tuple.
 …
 Mass assignment has the following form:
 \begin{cfa}
 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;
+[ �\emph{lvalue}�, ... , �\emph{lvalue}� ] = �\emph{expr}�;
 \end{cfa}
 \index{lvalue}
 The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, \ie any data object that can appear on the left-hand side of a conventional assignment statement.
 ©$\emph{expr}$© is any standard arithmetic expression.
+�$\emph{expr}$� is any standard arithmetic expression.
 Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
 …
 *a1 = t; *a2 = t; *a3 = t;
 \end{cfa}
 The temporary ©t© is necessary to store the value of the expression to eliminate conversion issues.
+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.
 In this case, ©y[i]© uses the previous value of ©i© and not the new value set at the beginning of the mass assignment.
+In this case, �y[i]� uses the previous value of �i� and not the new value set at the beginning of the mass assignment.
 …
 Multiple assignment has the following form:
 \begin{cfa}
 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ];
+[ �\emph{lvalue}�, ... , �\emph{lvalue}� ] = [ �\emph{expr}�, ... , �\emph{expr}� ];
 \end{cfa}
 \index{lvalue}
 …
 [ x, y, z ] = [ 1, 2, 3 ];
 \end{cfa}
 Here, the values ©1©, ©2© and ©3© are assigned, respectively, to the variables ©x©, ©y© and ©z©.
+Here, the values �1�, �2� and �3� are assigned, respectively, to the variables �x�, �y� and �z�.
  A more complex example is:
 \begin{cfa}
 [ i, y[ i ], z ] = [ 1, i, a + b ];
 \end{cfa}
 Here, the values ©1©, ©i© and ©a + b© are assigned to the variables ©i©, ©y[i]© and ©z©, respectively.
+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:
 …
 [ x, y ] = [ y, x ];
 \end{cfa}
 correctly interchanges (swaps) the values stored in ©x© and ©y©.
+correctly interchanges (swaps) the values stored in �x� and �y�.
 The following cases are errors:
 \begin{cfa}
 …
 both these examples produce indeterminate results:
 \begin{cfa}
 f( x++, x++ );                          §\C{// C routine call with side effects in arguments}§
 [ v1, v2 ] = [ x++, x++ ];      §\C{// side effects in righthand side of multiple assignment}§
+f( x++, x++ );                          �\C{// C routine call with side effects in arguments}�
+[ v1, v2 ] = [ x++, x++ ];      �\C{// side effects in righthand side of multiple assignment}�
 \end{cfa}
 …
 Cascade assignment has the following form:
 \begin{cfa}
 §\emph{tuple}§ = §\emph{tuple}§ = ... = §\emph{tuple}§;
+�\emph{tuple}� = �\emph{tuple}� = ... = �\emph{tuple}�;
 \end{cfa}
 and it has the same parallel semantics as for mass and multiple assignment.
 …
 Its general form is:
 \begin{cfa}
 §\emph{expr}§ . [ §\emph{fieldlist}§ ]
 §\emph{expr}§ -> [ §\emph{fieldlist}§ ]
 \end{cfa}
 \emph{expr} is any expression yielding a value of type record, \eg ©struct©, ©union©.
+�\emph{expr}� . [ �\emph{fieldlist}� ]
+�\emph{expr}� -> [ �\emph{fieldlist}� ]
+\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
 …
         double f4;
 } v;
 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 )}§
+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{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:
+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{cfa}
 struct inner {
 …
 \begin{cfa}
 int x = 1, y = 2, z = 3;
 sout | x ®|® y ®|® z | endl;
+sout | x �|� y �|� z | endl;
 \end{cfa}
+&
 \begin{cfa}
 cout << x ®<< " "® << y ®<< " "® << z << endl;
+cout << x �<< " "� << y �<< " "� << z << endl;
 \end{cfa}
 \\
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 ® ®2® ®3
+� �2� �3
 \end{cfa}
+&
 …
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 [int, [ int, int ] ] t1 = [ 1, [ 2, 3 ] ], t2 = [ 3, [ 4, 5 ] ];
 sout | t1 | t2 | endl;                                  §\C{// print tuples}§
+sout | t1 | t2 | endl;                                  �\C{// print tuples}�
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,belowskip=0pt]
 ®, ®2®, ®3 3®, ®4®, ®5
+�, �2�, �3 3�, �4�, �5
 \end{cfa}
 Finally, \CFA uses the logical-or operator for I/O as it is the lowest-priority overloadable operator, other than assignment.
 …
+&
 \begin{cfa}
 cout << x * 3 << y + 1 << ®(®z << 2®)® << ®(®x == y®)® << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
+cout << x * 3 << y + 1 << �(�z << 2�)� << �(�x == y�)� << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
 \end{cfa}
 \\
 …
 \item
 A separator does not appear before a C string starting with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off,basicstyle=\tt]@([{=$£¥¡¿«@
+A separator does not appear before a C string starting with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off,basicstyle=\tt]@([{=$�����@
 %$
 \begin{cfa}[mathescape=off]
 sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
                 | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
+sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x �" | 6 | "x �"
+                | 7 | "x �" | 8 | "x �" | 9 | "x �" | 10 | endl;
 \end{cfa}
 %$
 \begin{cfa}[mathescape=off,basicstyle=\tt,showspaces=true,aboveskip=0pt,belowskip=0pt]
 x ®(®1 x ®[®2 x ®{®3 x ®=®4 x ®$®5 x ®£®6 x ®¥®7 x ®¡®8 x ®¿®9 x ®«®10
+x �(�1 x �[�2 x �{�3 x �=�4 x �$�5 x ���6 x ���7 x ���8 x ���9 x ���10
 \end{cfa}
 %$
 where \lstinline[basicstyle=\tt]@¡¿@ are inverted opening exclamation and question marks, and \lstinline[basicstyle=\tt]@«@ is an opening citation mark.
 \item
 {\lstset{language=CFA,deletedelim=**[is][]{¢}{¢}}
 A seperator does not appear after a C string ending with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[basicstyle=\tt]@,.;!?)]}%¢»@
+where \lstinline[basicstyle=\tt]@��@ are inverted opening exclamation and question marks, and \lstinline[basicstyle=\tt]@�@ is an opening citation mark.
+\item
+{\lstset{language=CFA,deletedelim=**[is][]{�}{�}}
+A seperator does not appear after a C string ending with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[basicstyle=\tt]@,.;!?)]}%��@
 \begin{cfa}[belowskip=0pt]
 sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
                 | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
+                | 7 | "� x" | 8 | "� x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
 \end{cfa}
 \begin{cfa}[basicstyle=\tt,showspaces=true,aboveskip=0pt,belowskip=0pt]
 ®,® x 2®.® x 3®;® x 4®!® x 5®?® x 6®%® x 7§\color{red}\textcent§ x 8®»® x 9®)® x 10®]® x 11®}® x
+�,� x 2�.� x 3�;� x 4�!� x 5�?� x 6�%� x 7�\color{red}\textcent� x 8��� x 9�)� x 10�]� x 11�}� x
 \end{cfa}}%
 where \lstinline[basicstyle=\tt]@»@ is a closing citation mark.
+where \lstinline[basicstyle=\tt]@�@ is a closing citation mark.
 \item
 …
 \end{cfa}
 \begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
 x®`®1®`®x§\color{red}\texttt{'}§2§\color{red}\texttt{'}§x§\color{red}\texttt{"}§3§\color{red}\texttt{"}§x®:®4®:®x® ®5® ®x®      ®6®     ®x
+x�`�1�`�x�\color{red}\texttt{'}�2�\color{red}\texttt{'}�x�\color{red}\texttt{"}�3�\color{red}\texttt{"}�x�:�4�:�x� �5� �x�      �6�     �x
 \end{cfa}
 …
 If a space is desired before or after one of the special string start/end characters, simply insert a space.
 \begin{cfa}[belowskip=0pt]
 sout | "x (§\color{red}\texttt{\textvisiblespace}§" | 1 | "§\color{red}\texttt{\textvisiblespace}§) x" | 2 | "§\color{red}\texttt{\textvisiblespace}§, x" | 3 | "§\color{red}\texttt{\textvisiblespace}§:x:§\color{red}\texttt{\textvisiblespace}§" | 4 | endl;
+sout | "x (�\color{red}\texttt{\textvisiblespace}�" | 1 | "�\color{red}\texttt{\textvisiblespace}�) x" | 2 | "�\color{red}\texttt{\textvisiblespace}�, x" | 3 | "�\color{red}\texttt{\textvisiblespace}�:x:�\color{red}\texttt{\textvisiblespace}�" | 4 | endl;
 \end{cfa}
 \begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
 x (® ®1® ®) x 2® ®, x 3® ®:x:® ®4
+x (� �1� �) x 2� �, x 3� �:x:� �4
 \end{cfa}
 \end{enumerate}
 …
 \begin{enumerate}
 \item
 Routines \Indexc{sepSet}\index{manipulator!sepSet@©sepSet©} and \Indexc{sepGet}\index{manipulator!sepGet@©sepGet©} set and get the separator string.
 The separator string can be at most 16 characters including the ©'\0'© string terminator (15 printable characters).
+Routines \Indexc{sepSet}\index{manipulator!sepSet@�sepSet�} and \Indexc{sepGet}\index{manipulator!sepGet@�sepGet�} set and get the separator string.
+The separator string can be at most 16 characters including the �'\0'� string terminator (15 printable characters).
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sepSet( sout, ", $" );                                          §\C{// set separator from " " to ", \$"}§
 sout | 1 | 2 | 3 | " \"" | ®sepGet( sout )® | "\"" | endl;
+sepSet( sout, ", $" );                                          �\C{// set separator from " " to ", \$"}�
+sout | 1 | 2 | 3 | " \"" | �sepGet( sout )� | "\"" | endl;
 \end{cfa}
 %$
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
 ®, $®2®, $®3 ®", $"®
+�, $�2�, $�3 �", $"�
 \end{cfa}
 %$
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sepSet( sout, " " );                                            §\C{// reset separator to " "}§
 sout | 1 | 2 | 3 | " \"" | ®sepGet( sout )® | "\"" | endl;
+sepSet( sout, " " );                                            �\C{// reset separator to " "}�
+sout | 1 | 2 | 3 | " \"" | �sepGet( sout )� | "\"" | endl;
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
 ® ®2® ®3 ®" "®
 \end{cfa}
 \item
 Routine \Indexc{sepSetTuple}\index{manipulator!sepSetTuple@©sepSetTuple©} and \Indexc{sepGetTuple}\index{manipulator!sepGetTuple@©sepGetTuple©} get and set the tuple separator-string.
 The tuple separator-string can be at most 16 characters including the ©'\0'© string terminator (15 printable characters).
+� �2� �3 �" "�
+\end{cfa}
+\item
+Routine \Indexc{sepSetTuple}\index{manipulator!sepSetTuple@�sepSetTuple�} and \Indexc{sepGetTuple}\index{manipulator!sepGetTuple@�sepGetTuple�} get and set the tuple separator-string.
+The tuple separator-string can be at most 16 characters including the �'\0'� string terminator (15 printable characters).
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sepSetTuple( sout, " " );                                       §\C{// set tuple separator from ", " to " "}§
 sout | t1 | t2 | " \"" | ®sepGetTuple( sout )® | "\"" | endl;
+sepSetTuple( sout, " " );                                       �\C{// set tuple separator from ", " to " "}�
+sout | t1 | t2 | " \"" | �sepGetTuple( sout )� | "\"" | endl;
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
 2 3 4 ®" "®
+2 3 4 �" "�
 \end{cfa}
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sepSetTuple( sout, ", " );                                      §\C{// reset tuple separator to ", "}§
 sout | t1 | t2 | " \"" | ®sepGetTuple( sout )® | "\"" | endl;
+sepSetTuple( sout, ", " );                                      �\C{// reset tuple separator to ", "}�
+sout | t1 | t2 | " \"" | �sepGetTuple( sout )� | "\"" | endl;
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
 , 2, 3, 4 ®", "®
 \end{cfa}
 \item
 Manipulators \Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} \emph{locally} toggle printing the separator, \ie the seperator is adjusted only with respect to the next printed item.
+, 2, 3, 4 �", "�
+\end{cfa}
+\item
+Manipulators \Indexc{sepOn}\index{manipulator!sepOn@�sepOn�} and \Indexc{sepOff}\index{manipulator!sepOff@�sepOff�} \emph{locally} toggle printing the separator, \ie the seperator is adjusted only with respect to the next printed item.
 \begin{cfa}[mathescape=off,belowskip=0pt]
 sout | sepOn | 1 | 2 | 3 | sepOn | endl;        §\C{// separator at start/end of line}§
+sout | sepOn | 1 | 2 | 3 | sepOn | endl;        �\C{// separator at start/end of line}�
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+® ®1 2 3® ®
+� �1 2 3� �
 \end{cfa}
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sout | 1 | sepOff | 2 | 3 | endl;                       §\C{// locally turn off implicit separator}§
+sout | 1 | sepOff | 2 | 3 | endl;                       �\C{// locally turn off implicit separator}�
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 …
 The tuple separator also responses to being turned on and off.
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sout | sepOn | t1 | sepOff | t2 | endl;         §\C{// locally turn on/off implicit separation}§
+sout | sepOn | t1 | sepOff | t2 | endl;         �\C{// locally turn on/off implicit separation}�
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 …
 \item
 Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} \emph{globally} toggle printing the separator, \ie the seperator is adjusted with respect to all subsequent printed items, unless locally adjusted.
+Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@�sepDisable�} and \Indexc{sepEnable}\index{manipulator!sepEnable@�sepEnable�} \emph{globally} toggle printing the separator, \ie the seperator is adjusted with respect to all subsequent printed items, unless locally adjusted.
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// globally turn off implicit separation}§
+sout | sepDisable | 1 | 2 | 3 | endl;           �\C{// globally turn off implicit separation}�
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 …
 \end{cfa}
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sout | 1 | ®sepOn® | 2 | 3 | endl;                      §\C{// locally turn on implicit separator}§
+sout | 1 | �sepOn� | 2 | 3 | endl;                      �\C{// locally turn on implicit separator}�
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 ® ®23
+� �23
 \end{cfa}
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sout | sepEnable | 1 | 2 | 3 | endl;            §\C{// globally turn on implicit separation}§
+sout | sepEnable | 1 | 2 | 3 | endl;            �\C{// globally turn on implicit separation}�
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 …
         sout | '1' | '2' | '3' | endl;
         sout | 1 | "" | 2 | "" | 3 | endl;
         sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
                 | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
+        sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x �" | 6 | "x �"
+                | 7 | "x �" | 8 | "x �" | 9 | "x �" | 10 | endl;
         sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
                 | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
+                | 7 | "� x" | 8 | "� x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
         sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx" | endl;
         sout | "x ( " | 1 | " ) x" | 2 | " , x" | 3 | " :x: " | 4 | endl;
 …
 In \CFA, as in C, all scalar types can be incremented and
 decremented, which is defined in terms of adding or subtracting 1.
 The operations ©&&©, ©||©, and ©!© can be applied to any scalar arguments and are defined in terms of comparison against 0 (ex. ©(a && b)© becomes ©(a != 0 && b != 0)©).
+The operations �&&�, �||�, and �!� can be applied to any scalar arguments and are defined in terms of comparison against 0 (ex. �(a && b)� becomes �(a != 0 && b != 0)�).
 In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to 0 as a special case.
 However, user-defined arithmetic types often need the equivalent of a 1 or 0 for their functions or operators, polymorphic functions often need 0 and 1 constants of a type matching their polymorphic parameters, and user-defined pointer-like types may need a null value.
 Defining special constants for a user-defined type is more efficient than defining a conversion to the type from ©_Bool©.
+Defining special constants for a user-defined type is more efficient than defining a conversion to the type from �_Bool�.
 Why just 0 and 1? Why not other integers? No other integers have special status in C.
 …
 \begin{tabular}[t]{ll}
 %identifier & operation \\ \hline
 ©?[?]© & subscripting \impl{?[?]}\\
 ©?()© & function call \impl{?()}\\
 ©?++© & postfix increment \impl{?++}\\
 ©?--© & postfix decrement \impl{?--}\\
 ©++?© & prefix increment \impl{++?}\\
 ©--?© & prefix decrement \impl{--?}\\
 ©*?© & dereference \impl{*?}\\
 ©+?© & unary plus \impl{+?}\\
 ©-?© & arithmetic negation \impl{-?}\\
 ©~?© & bitwise negation \impl{~?}\\
 ©!?© & logical complement \impl{"!?}\\
 ©?*?© & multiplication \impl{?*?}\\
 ©?/?© & division \impl{?/?}\\
+�?[?]� & subscripting \impl{?[?]}\\
+�?()� & function call \impl{?()}\\
+�?++� & postfix increment \impl{?++}\\
+�?--� & postfix decrement \impl{?--}\\
+�++?� & prefix increment \impl{++?}\\
+�--?� & prefix decrement \impl{--?}\\
+�*?� & dereference \impl{*?}\\
+�+?� & unary plus \impl{+?}\\
+�-?� & arithmetic negation \impl{-?}\\
+�~?� & bitwise negation \impl{~?}\\
+�!?� & logical complement \impl{"!?}\\
+�?*?� & multiplication \impl{?*?}\\
+�?/?� & division \impl{?/?}\\
 \end{tabular}\hfil
 \begin{tabular}[t]{ll}
 %identifier & operation \\ \hline
 ©?%?© & remainder \impl{?%?}\\
 ©?+?© & addition \impl{?+?}\\
 ©?-?© & subtraction \impl{?-?}\\
 ©?<<?© & left shift \impl{?<<?}\\
 ©?>>?© & right shift \impl{?>>?}\\
 ©?<?© & less than \impl{?<?}\\
 ©?<=?© & less than or equal \impl{?<=?}\\
 ©?>=?© & greater than or equal \impl{?>=?}\\
 ©?>?© & greater than \impl{?>?}\\
 ©?==?© & equality \impl{?==?}\\
 ©?!=?© & inequality \impl{?"!=?}\\
 ©?&?© & bitwise AND \impl{?&?}\\
+�?%?� & remainder \impl{?%?}\\
+�?+?� & addition \impl{?+?}\\
+�?-?� & subtraction \impl{?-?}\\
+�?<<?� & left shift \impl{?<<?}\\
+�?>>?� & right shift \impl{?>>?}\\
+�?<?� & less than \impl{?<?}\\
+�?<=?� & less than or equal \impl{?<=?}\\
+�?>=?� & greater than or equal \impl{?>=?}\\
+�?>?� & greater than \impl{?>?}\\
+�?==?� & equality \impl{?==?}\\
+�?!=?� & inequality \impl{?"!=?}\\
+�?&?� & bitwise AND \impl{?&?}\\
 \end{tabular}\hfil
 \begin{tabular}[t]{ll}
 %identifier & operation \\ \hline
 ©?^?© & exclusive OR \impl{?^?}\\
 ©?|?© & inclusive OR \impl{?"|?}\\
 ©?=?© & simple assignment \impl{?=?}\\
 ©?*=?© & multiplication assignment \impl{?*=?}\\
 ©?/=?© & division assignment \impl{?/=?}\\
 ©?%=?© & remainder assignment \impl{?%=?}\\
 ©?+=?© & addition assignment \impl{?+=?}\\
 ©?-=?© & subtraction assignment \impl{?-=?}\\
 ©?<<=?© & left-shift assignment \impl{?<<=?}\\
 ©?>>=?© & right-shift assignment \impl{?>>=?}\\
 ©?&=?© & bitwise AND assignment \impl{?&=?}\\
 ©?^=?© & exclusive OR assignment \impl{?^=?}\\
 ©?|=?© & inclusive OR assignment \impl{?"|=?}\\
+�?^?� & exclusive OR \impl{?^?}\\
+�?|?� & inclusive OR \impl{?"|?}\\
+�?=?� & simple assignment \impl{?=?}\\
+�?*=?� & multiplication assignment \impl{?*=?}\\
+�?/=?� & division assignment \impl{?/=?}\\
+�?%=?� & remainder assignment \impl{?%=?}\\
+�?+=?� & addition assignment \impl{?+=?}\\
+�?-=?� & subtraction assignment \impl{?-=?}\\
+�?<<=?� & left-shift assignment \impl{?<<=?}\\
+�?>>=?� & right-shift assignment \impl{?>>=?}\\
+�?&=?� & bitwise AND assignment \impl{?&=?}\\
+�?^=?� & exclusive OR assignment \impl{?^=?}\\
+�?|=?� & inclusive OR assignment \impl{?"|=?}\\
 \end{tabular}
 \hfil
 …
 These identifiers are defined such that the question marks in the name identify the location of the operands.
 These operands represent the parameters to the functions, and define how the operands are mapped to the function call.
 For example, ©a + b© becomes ©?+?(a, b)©.
+For example, �a + b� becomes �?+?(a, b)�.
 In the example below, a new type, myComplex, is defined with an overloaded constructor, + operator, and string operator.
 …
 \end{itemize}
 In \CFA, ©typedef© provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
 \Indexc{gcc} provides ©typeof© to declare a secondary variable from a primary variable.
+In \CFA, �typedef� provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
+\Indexc{gcc} provides �typeof� to declare a secondary variable from a primary variable.
 \CFA also relies heavily on the specification of the left-hand side of assignment for type inferencing, so in many cases it is crucial to specify the type of the left-hand side to select the correct type of the right-hand expression.
 Only for overloaded routines with the same return type is variable type-inferencing possible.
 Finally, ©auto© presents the programming problem of tracking down a type when the type is actually needed.
+Finally, �auto� presents the programming problem of tracking down a type when the type is actually needed.
 For example, given
 \begin{cfa}
 auto j = ®...®
 \end{cfa}
 and the need to write a routine to compute using ©j©
 \begin{cfa}
 void rtn( ®...® parm );
+auto j = �...�
+\end{cfa}
+and the need to write a routine to compute using �j�
+\begin{cfa}
+void rtn( �...� parm );
 rtn( j );
 \end{cfa}
 A programmer must work backwards to determine the type of ©j©'s initialization expression, reconstructing the possibly long generic type-name.
+A programmer must work backwards to determine the type of �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.
 …
 At some point, a programmer wants the type of the variable to remain constant and the expression to be in error when it changes.
 Given ©typedef© and ©typeof© in \CFA, and the strong need to use the type of left-hand side in inferencing, auto type-inferencing is not supported at this time.
+Given �typedef� and �typeof� in \CFA, and the strong need to use the type of left-hand side in inferencing, auto type-inferencing is not supported at this time.
 Should a significant need arise, this feature can be revisited.
 …
 coroutine Fibonacci {
         int fn;                                                         §\C{// used for communication}§
+        int fn;                                                         �\C{// used for communication}�
 };
 void ?{}( Fibonacci * this ) {
 …
+}
 void main( Fibonacci * this ) {
         int fn1, fn2;                                           §\C{// retained between resumes}§
         this->fn = 0;                                           §\C{// case 0}§
+        int fn1, fn2;                                           �\C{// retained between resumes}�
+        this->fn = 0;                                           �\C{// case 0}�
         fn1 = this->fn;
         suspend();                                                      §\C{// return to last resume}§
         this->fn = 1;                                           §\C{// case 1}§
+        suspend();                                                      �\C{// return to last resume}�
+        this->fn = 1;                                           �\C{// case 1}�
         fn2 = fn1;
         fn1 = this->fn;
         suspend();                                                      §\C{// return to last resume}§
         for ( ;; ) {                                            §\C{// general case}§
+        suspend();                                                      �\C{// return to last resume}�
+        for ( ;; ) {                                            �\C{// general case}�
                 this->fn = fn1 + fn2;
                 fn2 = fn1;
                 fn1 = this->fn;
                 suspend();                                              §\C{// return to last resume}§
+                suspend();                                              �\C{// return to last resume}�
         } // for
+}
 int next( Fibonacci * this ) {
         resume( this );                                         §\C{// transfer to last suspend}§
+        resume( this );                                         �\C{// transfer to last suspend}�
         return this->fn;
+}
 …
 #include <thread>
 thread First  { signal_once * lock; };
 thread Second { signal_once * lock; };
 void ?{}( First * this, signal_once* lock ) { this->lock = lock; }
 void ?{}( Second * this, signal_once* lock ) { this->lock = lock; }
 void main( First * this ) {
         for ( int i = 0; i < 10; i += 1 ) {
+thread First  { semaphore* lock; };
+thread Second { semaphore* lock; };
+void ?{}( First * this, semaphore* lock ) { this->lock = lock; }
+void ?{}( Second * this, semaphore* lock ) { this->lock = lock; }
+void main(First* this) {
+        for(int i = 0; i < 10; i++) {
                 sout | "First : Suspend No." | i + 1 | endl;
                 yield();
+        }
         signal( this->lock );
+}
 void main( Second * this ) {
         wait( this->lock );
         for ( int i = 0; i < 10; i += 1 ) {
+        V(this->lock);
+}
+void main(Second* this) {
+        P(this->lock);
+        for(int i = 0; i < 10; i++) {
                 sout | "Second : Suspend No." | i + 1 | endl;
                 yield();
 …
+}
+int main( void ) {
+        signal_once lock;
+int main(int argc, char* argv[]) {
+        semaphore lock = { 0 };
         sout | "User main begin" | endl;
+        {
 …
 In \CFA, multiple definitions are not necessary.
 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:
+For example, the following code compiles, even though �isOdd� was not declared before being called:
 \begin{cfa}
 bool isEven(unsigned int x) {
 …
 C has a number of syntax ambiguities, which are resolved by taking the longest sequence of overlapping characters that constitute a token.
 For example, the program fragment ©x+++++y© is parsed as \lstinline[showspaces=true]@x ++ ++ + y@ because operator tokens ©++© and ©+© overlap.
+For example, the program fragment �x+++++y� is parsed as \lstinline[showspaces=true]@x ++ ++ + y@ because operator tokens �++� and �+� overlap.
 Unfortunately, the longest sequence violates a constraint on increment operators, even though the parse \lstinline[showspaces=true]@x ++ + ++ y@ might yield a correct expression.
 Hence, C programmers are aware that spaces have to added to disambiguate certain syntactic cases.
 In \CFA, there are ambiguous cases with dereference and operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be interpreted as:
 \begin{cfa}
 *?§\color{red}\textvisiblespace§*?              §\C{// dereference operator, dereference operator}§
 *§\color{red}\textvisiblespace§?*?              §\C{// dereference, multiplication operator}§
+In \CFA, there are ambiguous cases with dereference and operator identifiers, \eg �int *?*?()�, where the string �*?*?� can be interpreted as:
+\begin{cfa}
+*?�\color{red}\textvisiblespace�*?              �\C{// dereference operator, dereference operator}�
+*�\color{red}\textvisiblespace�?*?              �\C{// dereference, multiplication operator}�
 \end{cfa}
 By default, the first interpretation is selected, which does not yield a meaningful parse.
 …
 Otherwise a space is needed between the unary operator and operator identifier to disambiguate this common case.
 A similar issue occurs with the dereference, ©*?(...)©, and routine-call, ©?()(...)© identifiers.
+A similar issue occurs with the dereference, �*?(...)�, and routine-call, �?()(...)� identifiers.
 The ambiguity occurs when the deference operator has no parameters:
 \begin{cfa}
 *?()§\color{red}\textvisiblespace...§ ;
 *?()§\color{red}\textvisiblespace...§(...) ;
+*?()�\color{red}\textvisiblespace...� ;
+*?()�\color{red}\textvisiblespace...�(...) ;
 \end{cfa}
 requiring arbitrary whitespace look-ahead for the routine-call parameter-list to disambiguate.
 However, the dereference operator \emph{must} have a parameter/argument to dereference ©*?(...)©.
 Hence, always interpreting the string ©*?()© as \lstinline[showspaces=true]@* ?()@ does not preclude any meaningful program.
+However, the dereference operator \emph{must} have a parameter/argument to dereference �*?(...)�.
+Hence, always interpreting the string �*?()� as \lstinline[showspaces=true]@* ?()@ does not preclude any meaningful program.
 The remaining cases are with the increment/decrement operators and conditional expression, \eg:
 \begin{cfa}
 i++?§\color{red}\textvisiblespace...§(...);
 i?++§\color{red}\textvisiblespace...§(...);
+i++?�\color{red}\textvisiblespace...�(...);
+i?++�\color{red}\textvisiblespace...�(...);
 \end{cfa}
 requiring arbitrary whitespace look-ahead for the operator parameter-list, even though that interpretation is an incorrect expression (juxtaposed identifiers).
 Therefore, it is necessary to disambiguate these cases with a space:
 \begin{cfa}
 i++§\color{red}\textvisiblespace§? i : 0;
 i?§\color{red}\textvisiblespace§++i : 0;
+i++�\color{red}\textvisiblespace�? i : 0;
+i?�\color{red}\textvisiblespace�++i : 0;
 \end{cfa}
 …
 \begin{tabular}{llll}
 \begin{tabular}{@{}l@{}}
 ©_AT©                   \\
 ©catch©                 \\
 ©catchResume©   \\
 ©choose©                \\
 ©coroutine©             \\
 ©disable©               \\
+�_AT�                   \\
+�catch�                 \\
+�catchResume�   \\
+�choose�                \\
+�coroutine�             \\
+�disable�               \\
 \end{tabular}
+&
 \begin{tabular}{@{}l@{}}
 ©dtype©                 \\
 ©enable©                \\
 ©fallthrough©   \\
 ©fallthru©              \\
 ©finally©               \\
 ©forall©                \\
+�dtype�                 \\
+�enable�                \\
+�fallthrough�   \\
+�fallthru�              \\
+�finally�               \\
+�forall�                \\
 \end{tabular}
+&
 \begin{tabular}{@{}l@{}}
 ©ftype©                 \\
 ©lvalue©                \\
 ©monitor©               \\
 ©mutex©                 \\
 ©one_t©                 \\
 ©otype©                 \\
+�ftype�                 \\
+�lvalue�                \\
+�monitor�               \\
+�mutex�                 \\
+�one_t�                 \\
+�otype�                 \\
 \end{tabular}
+&
 \begin{tabular}{@{}l@{}}
 ©throw©                 \\
 ©throwResume©   \\
 ©trait©                 \\
 ©try©                   \\
 ©ttype©                 \\
 ©zero_t©                \\
+�throw�                 \\
+�throwResume�   \\
+�trait�                 \\
+�try�                   \\
+�ttype�                 \\
+�zero_t�                \\
 \end{tabular}
 \end{tabular}
 …
 \begin{description}
 \item[Change:] drop K\&R C declarations \\
 K\&R declarations allow an implicit base-type of ©int©, if no type is specified, plus an alternate syntax for declaring parameters.
+K\&R declarations allow an implicit base-type of �int�, if no type is specified, plus an alternate syntax for declaring parameters.
 \eg:
 \begin{cfa}
 x;                                                              §\C{// int x}§
 *y;                                                             §\C{// int *y}§
 f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
 g( p1, p2 ) int p1, p2;                 §\C{// int g( int p1, int p2 );}§
+x;                                                              �\C{// int x}�
+*y;                                                             �\C{// int *y}�
+f( p1, p2 );                                    �\C{// int f( int p1, int p2 );}�
+g( p1, p2 ) int p1, p2;                 �\C{// int g( int p1, int p2 );}�
 \end{cfa}
 \CFA supports K\&R routine definitions:
 \begin{cfa}
 f( a, b, c )                                    §\C{// default int return}§
         int a, b; char c                        §\C{// K\&R parameter declarations}§
+f( a, b, c )                                    �\C{// default int return}�
+        int a, b; char c                        �\C{// K\&R parameter declarations}�
+{
         ...
 …
 \item
 \begin{description}
 \item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
+\item[Change:] type of character literal �int� to �char� to allow more intuitive overloading:
 \begin{cfa}
 int rtn( int i );
 int rtn( char c );
 rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
 \end{cfa}
 \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
+rtn( 'x' );                                             �\C{// programmer expects 2nd rtn to be called}�
+\end{cfa}
+\item[Rationale:] it is more intuitive for the call to �rtn� to match the second version of definition of �rtn� rather than the first.
+In particular, output of �char� variable now print a character rather than the decimal ASCII value of the character.
 \begin{cfa}
 sout | 'x' | " " | (int)'x' | endl;
 x 120
 \end{cfa}
 Having to cast ©'x'© to ©char© is non-intuitive.
+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{cfa}
 …
 no long work the same in \CFA programs.
 \item[Difficulty of converting:] simple
 \item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.
+\item[How widely used:] programs that depend upon �sizeof( 'x' )� are rare and can be changed to �sizeof(char)�.
 \end{description}
 \item
 \begin{description}
 \item[Change:] make string literals ©const©:
 \begin{cfa}
 char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
 char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
 \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[Change:] make string literals �const�:
+\begin{cfa}
+char * p = "abc";                               �\C{// valid in C, deprecated in \CFA}�
+char * q = expr ? "abc" : "de"; �\C{// valid in C, invalid in \CFA}�
+\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{cfa}
 char * p = "abc";
 p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
+p[0] = 'w';                                             �\C{// segment fault or change constant literal}�
 \end{cfa}
 The same problem occurs when passing a string literal to a routine that changes its argument.
 \item[Effect on original feature:] change to semantics of well-defined feature.
 \item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.
+\item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to �char *�.
 \item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
 \end{description}
 …
 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
 \begin{cfa}
 int i;                                                  §\C{// forward definition}§
 int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
 int i = 0;                                              §\C{// definition}§
+int i;                                                  �\C{// forward definition}�
+int *j = �&i�;                                  �\C{// forward reference, valid in C, invalid in \CFA}�
+int i = 0;                                              �\C{// definition}�
 \end{cfa}
 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
 …
 \begin{cfa}
 struct X { int i; struct X *next; };
 static struct X a;                              §\C{// forward definition}§
 static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
 static struct X a = { 1, &b };  §\C{// definition}§
+static struct X a;                              �\C{// forward definition}�
+static struct X b = { 0, �&a� };        �\C{// forward reference, valid in C, invalid in \CFA}�
+static struct X a = { 1, &b };  �\C{// definition}�
 \end{cfa}
 \item[Rationale:] avoids having different initialization rules for builtin types and user-defined types.
 …
 \item
 \begin{description}
 \item[Change:] have ©struct© introduce a scope for nested types:
 \begin{cfa}
 enum ®Colour® { R, G, B, Y, C, M };
+\item[Change:] have �struct� introduce a scope for nested types:
+\begin{cfa}
+enum �Colour� { R, G, B, Y, C, M };
 struct Person {
         enum ®Colour® { R, G, B };      §\C{// nested type}§
         struct Face {                           §\C{// nested type}§
                 ®Colour® Eyes, Hair;    §\C{// type defined outside (1 level)}§
+        enum �Colour� { R, G, B };      �\C{// nested type}�
+        struct Face {                           �\C{// nested type}�
+                �Colour� Eyes, Hair;    �\C{// type defined outside (1 level)}�
         };
         ®.Colour® shirt;                        §\C{// type defined outside (top level)}§
         ®Colour® pants;                         §\C{// type defined same level}§
         Face looks[10];                         §\C{// type defined same level}§
+        �.Colour� shirt;                        �\C{// type defined outside (top level)}�
+        �Colour� pants;                         �\C{// type defined same level}�
+        Face looks[10];                         �\C{// type defined same level}�
 };
+®Colour® c = R;                                 §\C{// type/enum defined same level}§
 Person®.Colour® pc = Person®.®R;        §\C{// type/enum defined inside}§
 Person®.®Face pretty;                   §\C{// type defined inside}§
+�Colour� c = R;                                 �\C{// type/enum defined same level}�
+Person�.Colour� pc = Person�.�R;        �\C{// type/enum defined inside}�
+Person�.�Face pretty;                   �\C{// type defined inside}�
 \end{cfa}
 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, \ie the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC{}}.
 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
 \item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.
+Nested types are not hoisted and can be referenced using the field selection operator ``�.�'', unlike the \CC scope-resolution operator ``�::�''.
+\item[Rationale:] �struct� scope is crucial to \CFA as an information structuring and hiding mechanism.
 \item[Effect on original feature:] change to semantics of well-defined feature.
 \item[Difficulty of converting:] Semantic transformation.
 …
 \item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
 \begin{cfa}
 struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
+struct Y;                                               �\C{// struct Y and struct X are at the same scope}�
 struct X {
         struct Y { /* ... */ } y;
 …
 \begin{description}
 \item[Change:] comma expression is disallowed as subscript
 \item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new style arrays.
+\item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: �x[i,j]� instead of �x[i][j]�, and this syntactic form then taken by \CFA for new style arrays.
 \item[Effect on original feature:] change to semantics of well-defined feature.
 \item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©
+\item[Difficulty of converting:] semantic transformation of �x[i,j]� to �x[(i,j)]�
 \item[How widely used:] seldom.
 \end{description}
 …
 \end{tabular}
 \end{quote2}
 For the prescribed head-files, \CFA uses header interposition to wraps these includes in an ©extern "C"©;
+For the prescribed head-files, \CFA uses header interposition to wraps these includes in an �extern "C"�;
 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
 All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
 For \Index*[C++]{\CC{}}, the name-mangling issue is handled implicitly because most C header-files are augmented with checks for preprocessor variable ©__cplusplus©, which adds appropriate ©extern "C"© qualifiers.
+All other C header files must be explicitly wrapped in �extern "C"� to prevent name mangling.
+For \Index*[C++]{\CC{}}, the name-mangling issue is handled implicitly because most C header-files are augmented with checks for preprocessor variable �__cplusplus�, which adds appropriate �extern "C"� qualifiers.
 …
                 &                                       & \multicolumn{1}{c|}{fill}     & resize        & alignment     & array \\
 \hline
 C               & ©malloc©                      & no                    & no            & no            & no    \\
                 & ©calloc©                      & yes (0 only)  & no            & no            & yes   \\
                 & ©realloc©                     & no/copy               & yes           & no            & no    \\
                 & ©memalign©            & no                    & no            & yes           & no    \\
                 & ©posix_memalign©      & no                    & no            & yes           & no    \\
 C11             & ©aligned_alloc©       & no                    & no            & yes           & no    \\
 \CFA    & ©alloc©                       & no/copy/yes   & no/yes        & no            & yes   \\
                 & ©align_alloc©         & no/yes                & no            & yes           & yes   \\
+C               & �malloc�                      & no                    & no            & no            & no    \\
+                & �calloc�                      & yes (0 only)  & no            & no            & yes   \\
+                & �realloc�                     & no/copy               & yes           & no            & no    \\
+                & �memalign�            & no                    & no            & yes           & no    \\
+                & �posix_memalign�      & no                    & no            & yes           & no    \\
+C11             & �aligned_alloc�       & no                    & no            & yes           & no    \\
+\CFA    & �alloc�                       & no/copy/yes   & no/yes        & no            & yes   \\
+                & �align_alloc�         & no/yes                & no            & yes           & yes   \\
 \end{tabular}
 \end{center}
 It is impossible to resize with alignment because the underlying ©realloc© allocates storage if more space is needed, and it does not honour alignment from the original allocation.
+It is impossible to resize with alignment because the underlying �realloc� allocates storage if more space is needed, and it does not honour alignment from the original allocation.
 \leavevmode
 …
 // C unsafe allocation
 extern "C" {
 void * mallac( size_t size );§\indexc{memset}§
 void * calloc( size_t dim, size_t size );§\indexc{calloc}§
 void * realloc( void * ptr, size_t size );§\indexc{realloc}§
 void * memalign( size_t align, size_t size );§\indexc{memalign}§
 int posix_memalign( void ** ptr, size_t align, size_t size );§\indexc{posix_memalign}§
+}
 // §\CFA§ safe equivalents, i.e., implicit size specification
+void * mallac( size_t size );�\indexc{memset}�
+void * calloc( size_t dim, size_t size );�\indexc{calloc}�
+void * realloc( void * ptr, size_t size );�\indexc{realloc}�
+void * memalign( size_t align, size_t size );�\indexc{memalign}�
+int posix_memalign( void ** ptr, size_t align, size_t size );�\indexc{posix_memalign}�
+}
+// �\CFA� safe equivalents, i.e., implicit size specification
 forall( dtype T | sized(T) ) T * malloc( void );
 forall( dtype T | sized(T) ) T * calloc( size_t dim );
 …
 forall( dtype T | sized(T) ) int posix_memalign( T ** ptr, size_t align );
 // §\CFA§ safe general allocation, fill, resize, array
 forall( dtype T | sized(T) ) T * alloc( void );§\indexc{alloc}§
+// �\CFA� safe general allocation, fill, resize, array
+forall( dtype T | sized(T) ) T * alloc( void );�\indexc{alloc}�
 forall( dtype T | sized(T) ) T * alloc( char fill );
 forall( dtype T | sized(T) ) T * alloc( size_t dim );
 …
 forall( dtype T | sized(T) ) T * alloc( T ptr[], size_t dim, char fill );
 // §\CFA§ safe general allocation, align, fill, array
+// �\CFA� safe general allocation, align, fill, array
 forall( dtype T | sized(T) ) T * align_alloc( size_t align );
 forall( dtype T | sized(T) ) T * align_alloc( size_t align, char fill );
 …
+}
 // §\CFA§ safe initialization/copy, i.e., implicit size specification
 forall( dtype T | sized(T) ) T * memset( T * dest, char c );§\indexc{memset}§
 forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
 // §\CFA§ safe initialization/copy array
+// �\CFA� safe initialization/copy, i.e., implicit size specification
+forall( dtype T | sized(T) ) T * memset( T * dest, char c );�\indexc{memset}�
+forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );�\indexc{memcpy}�
+// �\CFA� safe initialization/copy array
 forall( dtype T | sized(T) ) T * memset( T dest[], size_t dim, char c );
 forall( dtype T | sized(T) ) T * memcpy( T dest[], const T src[], size_t dim );
 // §\CFA§ allocation/deallocation and constructor/destructor
 forall( dtype T | sized(T), ttype Params | { void ?{}( T *, Params ); } ) T * new( Params p );§\indexc{new}§
 forall( dtype T | { void ^?{}( T * ); } ) void delete( T * ptr );§\indexc{delete}§
+// �\CFA� allocation/deallocation and constructor/destructor
+forall( dtype T | sized(T), ttype Params | { void ?{}( T *, Params ); } ) T * new( Params p );�\indexc{new}�
+forall( dtype T | { void ^?{}( T * ); } ) void delete( T * ptr );�\indexc{delete}�
 forall( dtype T, ttype Params | { void ^?{}( T * ); void delete( Params ); } )
   void delete( T * ptr, Params rest );
 // §\CFA§ allocation/deallocation and constructor/destructor, array
 forall( dtype T | sized(T), ttype Params | { void ?{}( T *, Params ); } ) T * anew( size_t dim, Params p );§\indexc{anew}§
 forall( dtype T | sized(T) | { void ^?{}( T * ); } ) void adelete( size_t dim, T arr[] );§\indexc{adelete}§
+// �\CFA� allocation/deallocation and constructor/destructor, array
+forall( dtype T | sized(T), ttype Params | { void ?{}( T *, Params ); } ) T * anew( size_t dim, Params p );�\indexc{anew}�
+forall( dtype T | sized(T) | { void ^?{}( T * ); } ) void adelete( size_t dim, T arr[] );�\indexc{adelete}�
 forall( dtype T | sized(T) | { void ^?{}( T * ); }, ttype Params | { void adelete( Params ); } )
   void adelete( size_t dim, T arr[], Params rest );
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 int ato( const char * ptr );§\indexc{ato}§
+int ato( const char * ptr );�\indexc{ato}�
 unsigned int ato( const char * ptr );
 long int ato( const char * ptr );
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 forall( otype T | { int ?<?( T, T ); } )        §\C{// location}§
 T * bsearch( T key, const T * arr, size_t dim );§\indexc{bsearch}§
 forall( otype T | { int ?<?( T, T ); } )        §\C{// position}§
+forall( otype T | { int ?<?( T, T ); } )        �\C{// location}�
+T * bsearch( T key, const T * arr, size_t dim );�\indexc{bsearch}�
+forall( otype T | { int ?<?( T, T ); } )        �\C{// position}�
 unsigned int bsearch( T key, const T * arr, size_t dim );
 forall( otype T | { int ?<?( T, T ); } )
 void qsort( const T * arr, size_t dim );§\indexc{qsort}§
+void qsort( const T * arr, size_t dim );�\indexc{qsort}�
 \end{cfa}
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 unsigned char abs( signed char );§\indexc{abs}§
+unsigned char abs( signed char );�\indexc{abs}�
 int abs( int );
 unsigned long int abs( long int );
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 void rand48seed( long int s );§\indexc{rand48seed}§
 char rand48();§\indexc{rand48}§
+void rand48seed( long int s );�\indexc{rand48seed}�
+char rand48();�\indexc{rand48}�
 int rand48();
 unsigned int rand48();
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );§\indexc{min}§
 forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );§\indexc{max}§
 forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
 forall( otype T ) void swap( T * t1, T * t2 );§\indexc{swap}§
+forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );�\indexc{min}�
+forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );�\indexc{max}�
+forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );�\indexc{clamp}�
+forall( otype T ) void swap( T * t1, T * t2 );�\indexc{swap}�
 \end{cfa}
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float ?%?( float, float );§\indexc{fmod}§
+float ?%?( float, float );�\indexc{fmod}�
 float fmod( float, float );
 double ?%?( double, double );
 …
 long double fmod( long double, long double );
 float remainder( float, float );§\indexc{remainder}§
+float remainder( float, float );�\indexc{remainder}�
 double remainder( double, double );
 long double remainder( long double, long double );
 [ int, float ] remquo( float, float );§\indexc{remquo}§
+[ int, float ] remquo( float, float );�\indexc{remquo}�
 float remquo( float, float, int * );
 [ int, double ] remquo( double, double );
 …
 [ int, float ] div( float, float );                                             // alternative name for remquo
 float div( float, float, int * );§\indexc{div}§
+float div( float, float, int * );�\indexc{div}�
 [ int, double ] div( double, double );
 double div( double, double, int * );
 …
 long double div( long double, long double, int * );
 float fma( float, float, float );§\indexc{fma}§
+float fma( float, float, float );�\indexc{fma}�
 double fma( double, double, double );
 long double fma( long double, long double, long double );
 float fdim( float, float );§\indexc{fdim}§
+float fdim( float, float );�\indexc{fdim}�
 double fdim( double, double );
 long double fdim( long double, long double );
 float nan( const char * );§\indexc{nan}§
+float nan( const char * );�\indexc{nan}�
 double nan( const char * );
 long double nan( const char * );
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float exp( float );§\indexc{exp}§
+float exp( float );�\indexc{exp}�
 double exp( double );
 long double exp( long double );
 …
 long double _Complex exp( long double _Complex );
 float exp2( float );§\indexc{exp2}§
+float exp2( float );�\indexc{exp2}�
 double exp2( double );
 long double exp2( long double );
 …
 long double _Complex exp2( long double _Complex );
 float expm1( float );§\indexc{expm1}§
+float expm1( float );�\indexc{expm1}�
 double expm1( double );
 long double expm1( long double );
 float log( float );§\indexc{log}§
+float log( float );�\indexc{log}�
 double log( double );
 long double log( long double );
 …
 long double _Complex log( long double _Complex );
 float log2( float );§\indexc{log2}§
+float log2( float );�\indexc{log2}�
 double log2( double );
 long double log2( long double );
 …
 long double _Complex log2( long double _Complex );
 float log10( float );§\indexc{log10}§
+float log10( float );�\indexc{log10}�
 double log10( double );
 long double log10( long double );
 …
 long double _Complex log10( long double _Complex );
 float log1p( float );§\indexc{log1p}§
+float log1p( float );�\indexc{log1p}�
 double log1p( double );
 long double log1p( long double );
 int ilogb( float );§\indexc{ilogb}§
+int ilogb( float );�\indexc{ilogb}�
 int ilogb( double );
 int ilogb( long double );
 float logb( float );§\indexc{logb}§
+float logb( float );�\indexc{logb}�
 double logb( double );
 long double logb( long double );
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float sqrt( float );§\indexc{sqrt}§
+float sqrt( float );�\indexc{sqrt}�
 double sqrt( double );
 long double sqrt( long double );
 …
 long double _Complex sqrt( long double _Complex );
 float cbrt( float );§\indexc{cbrt}§
+float cbrt( float );�\indexc{cbrt}�
 double cbrt( double );
 long double cbrt( long double );
 float hypot( float, float );§\indexc{hypot}§
+float hypot( float, float );�\indexc{hypot}�
 double hypot( double, double );
 long double hypot( long double, long double );
 float pow( float, float );§\indexc{pow}§
+float pow( float, float );�\indexc{pow}�
 double pow( double, double );
 long double pow( long double, long double );
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float sin( float );§\indexc{sin}§
+float sin( float );�\indexc{sin}�
 double sin( double );
 long double sin( long double );
 …
 long double _Complex sin( long double _Complex );
 float cos( float );§\indexc{cos}§
+float cos( float );�\indexc{cos}�
 double cos( double );
 long double cos( long double );
 …
 long double _Complex cos( long double _Complex );
 float tan( float );§\indexc{tan}§
+float tan( float );�\indexc{tan}�
 double tan( double );
 long double tan( long double );
 …
 long double _Complex tan( long double _Complex );
 float asin( float );§\indexc{asin}§
+float asin( float );�\indexc{asin}�
 double asin( double );
 long double asin( long double );
 …
 long double _Complex asin( long double _Complex );
 float acos( float );§\indexc{acos}§
+float acos( float );�\indexc{acos}�
 double acos( double );
 long double acos( long double );
 …
 long double _Complex acos( long double _Complex );
 float atan( float );§\indexc{atan}§
+float atan( float );�\indexc{atan}�
 double atan( double );
 long double atan( long double );
 …
 long double _Complex atan( long double _Complex );
 float atan2( float, float );§\indexc{atan2}§
+float atan2( float, float );�\indexc{atan2}�
 double atan2( double, double );
 long double atan2( long double, long double );
 float atan( float, float );                                                             // alternative name for atan2
 double atan( double, double );§\indexc{atan}§
+double atan( double, double );�\indexc{atan}�
 long double atan( long double, long double );
 \end{cfa}
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float sinh( float );§\indexc{sinh}§
+float sinh( float );�\indexc{sinh}�
 double sinh( double );
 long double sinh( long double );
 …
 long double _Complex sinh( long double _Complex );
 float cosh( float );§\indexc{cosh}§
+float cosh( float );�\indexc{cosh}�
 double cosh( double );
 long double cosh( long double );
 …
 long double _Complex cosh( long double _Complex );
 float tanh( float );§\indexc{tanh}§
+float tanh( float );�\indexc{tanh}�
 double tanh( double );
 long double tanh( long double );
 …
 long double _Complex tanh( long double _Complex );
 float asinh( float );§\indexc{asinh}§
+float asinh( float );�\indexc{asinh}�
 double asinh( double );
 long double asinh( long double );
 …
 long double _Complex asinh( long double _Complex );
 float acosh( float );§\indexc{acosh}§
+float acosh( float );�\indexc{acosh}�
 double acosh( double );
 long double acosh( long double );
 …
 long double _Complex acosh( long double _Complex );
 float atanh( float );§\indexc{atanh}§
+float atanh( float );�\indexc{atanh}�
 double atanh( double );
 long double atanh( long double );
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float erf( float );§\indexc{erf}§
+float erf( float );�\indexc{erf}�
 double erf( double );
 long double erf( long double );
 …
 long double _Complex erf( long double _Complex );
 float erfc( float );§\indexc{erfc}§
+float erfc( float );�\indexc{erfc}�
 double erfc( double );
 long double erfc( long double );
 …
 long double _Complex erfc( long double _Complex );
 float lgamma( float );§\indexc{lgamma}§
+float lgamma( float );�\indexc{lgamma}�
 double lgamma( double );
 long double lgamma( long double );
 …
 long double lgamma( long double, int * );
 float tgamma( float );§\indexc{tgamma}§
+float tgamma( float );�\indexc{tgamma}�
 double tgamma( double );
 long double tgamma( long double );
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float floor( float );§\indexc{floor}§
+float floor( float );�\indexc{floor}�
 double floor( double );
 long double floor( long double );
 float ceil( float );§\indexc{ceil}§
+float ceil( float );�\indexc{ceil}�
 double ceil( double );
 long double ceil( long double );
 float trunc( float );§\indexc{trunc}§
+float trunc( float );�\indexc{trunc}�
 double trunc( double );
 long double trunc( long double );
 float rint( float );§\indexc{rint}§
+float rint( float );�\indexc{rint}�
 long double rint( long double );
 long int rint( float );
 …
 long long int rint( long double );
 long int lrint( float );§\indexc{lrint}§
+long int lrint( float );�\indexc{lrint}�
 long int lrint( double );
 long int lrint( long double );
 …
 long long int llrint( long double );
 float nearbyint( float );§\indexc{nearbyint}§
+float nearbyint( float );�\indexc{nearbyint}�
 double nearbyint( double );
 long double nearbyint( long double );
 float round( float );§\indexc{round}§
+float round( float );�\indexc{round}�
 long double round( long double );
 long int round( float );
 …
 long long int round( long double );
 long int lround( float );§\indexc{lround}§
+long int lround( float );�\indexc{lround}�
 long int lround( double );
 long int lround( long double );
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 float copysign( float, float );§\indexc{copysign}§
+float copysign( float, float );�\indexc{copysign}�
 double copysign( double, double );
 long double copysign( long double, long double );
 float frexp( float, int * );§\indexc{frexp}§
+float frexp( float, int * );�\indexc{frexp}�
 double frexp( double, int * );
 long double frexp( long double, int * );
 float ldexp( float, int );§\indexc{ldexp}§
+float ldexp( float, int );�\indexc{ldexp}�
 double ldexp( double, int );
 long double ldexp( long double, int );
 [ float, float ] modf( float );§\indexc{modf}§
+[ float, float ] modf( float );�\indexc{modf}�
 float modf( float, float * );
 [ double, double ] modf( double );
 …
 long double modf( long double, long double * );
 float nextafter( float, float );§\indexc{nextafter}§
+float nextafter( float, float );�\indexc{nextafter}�
 double nextafter( double, double );
 long double nextafter( long double, long double );
 float nexttoward( float, long double );§\indexc{nexttoward}§
+float nexttoward( float, long double );�\indexc{nexttoward}�
 double nexttoward( double, long double );
 long double nexttoward( long double, long double );
 float scalbn( float, int );§\indexc{scalbn}§
+float scalbn( float, int );�\indexc{scalbn}�
 double scalbn( double, int );
 long double scalbn( long double, int );
 float scalbln( float, long int );§\indexc{scalbln}§
+float scalbln( float, long int );�\indexc{scalbln}�
 double scalbln( double, long int );
 long double scalbln( long double, long int );
 …
 \begin{cfa}
 void ?{}( Int * this );                                 §\C{// constructor}§
+void ?{}( Int * this );                                 �\C{// constructor}�
 void ?{}( Int * this, Int init );
 void ?{}( Int * this, zero_t );
 …
 void ^?{}( Int * this );
 Int ?=?( Int * lhs, Int rhs );                  §\C{// assignment}§
+Int ?=?( Int * lhs, Int rhs );                  �\C{// assignment}�
 Int ?=?( Int * lhs, long int rhs );
 Int ?=?( Int * lhs, unsigned long int rhs );
 …
 unsigned long int narrow( Int val );
 int ?==?( Int oper1, Int oper2 );               §\C{// comparison}§
+int ?==?( Int oper1, Int oper2 );               �\C{// comparison}�
 int ?==?( Int oper1, long int oper2 );
 int ?==?( long int oper2, Int oper1 );
 …
 int ?>=?( unsigned long int oper1, Int oper2 );
 Int +?( Int oper );                                             §\C{// arithmetic}§
+Int +?( Int oper );                                             �\C{// arithmetic}�
 Int -?( Int oper );
 Int ~?( Int oper );
 …
 Int ?>>=?( Int * lhs, mp_bitcnt_t shift );
 Int abs( Int oper );                                    §\C{// number functions}§
+Int abs( Int oper );                                    �\C{// number functions}�
 Int fact( unsigned long int N );
 Int gcd( Int oper1, Int oper2 );
 …
 Int sqrt( Int oper );
 forall( dtype istype | istream( istype ) ) istype * ?|?( istype * is, Int * mp );  §\C{// I/O}§
+forall( dtype istype | istream( istype ) ) istype * ?|?( istype * is, Int * mp );  �\C{// I/O}�
 forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype * os, Int mp );
 \end{cfa}
 …
 \hline
 \begin{cfa}
 #include <gmp>§\indexc{gmp}§
+#include <gmp>�\indexc{gmp}�
 int main( void ) {
         sout | "Factorial Numbers" | endl;
 …
+&
 \begin{cfa}
 #include <gmp.h>§\indexc{gmp.h}§
+#include <gmp.h>�\indexc{gmp.h}�
 int main( void ) {
         ®gmp_printf®( "Factorial Numbers\n" );
         ®mpz_t® fact;
         ®mpz_init_set_ui®( fact, 1 );
         ®gmp_printf®( "%d %Zd\n", 0, fact );
+        �gmp_printf�( "Factorial Numbers\n" );
+        �mpz_t� fact;
+        �mpz_init_set_ui�( fact, 1 );
+        �gmp_printf�( "%d %Zd\n", 0, fact );
         for ( unsigned int i = 1; i <= 40; i += 1 ) {
                 ®mpz_mul_ui®( fact, fact, i );
                 ®gmp_printf®( "%d %Zd\n", i, fact );
+                �mpz_mul_ui�( fact, fact, i );
+                �gmp_printf�( "%d %Zd\n", i, fact );
+        }
+}
 …
 \begin{cfa}[belowskip=0pt]
 // implementation
 struct Rational {§\indexc{Rational}§
+struct Rational {�\indexc{Rational}�
         long int numerator, denominator;                                        // invariant: denominator > 0
 }; // Rational
 Rational rational();                                    §\C{// constructors}§
+Rational rational();                                    �\C{// constructors}�
 Rational rational( long int n );
 Rational rational( long int n, long int d );
 …
 void ?{}( Rational * r, one_t );
 long int numerator( Rational r );               §\C{// numerator/denominator getter/setter}§
+long int numerator( Rational r );               �\C{// numerator/denominator getter/setter}�
 long int numerator( Rational r, long int n );
 long int denominator( Rational r );
 long int denominator( Rational r, long int d );
 int ?==?( Rational l, Rational r );             §\C{// comparison}§
+int ?==?( Rational l, Rational r );             �\C{// comparison}�
 int ?!=?( Rational l, Rational r );
 int ?<?( Rational l, Rational r );
 …
 int ?>=?( Rational l, Rational r );
 Rational -?( Rational r );                              §\C{// arithmetic}§
+Rational -?( Rational r );                              �\C{// arithmetic}�
 Rational ?+?( Rational l, Rational r );
 Rational ?-?( Rational l, Rational r );
 …
 Rational ?/?( Rational l, Rational r );
 double widen( Rational r );                             §\C{// conversion}§
+double widen( Rational r );                             �\C{// conversion}�
 Rational narrow( double f, long int md );

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 955d27e9 for doc/user

Legend:

doc/user/user.tex

Download in other formats: