Context Navigation

-                      re945826
+                      r0638c44
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Sat Apr 30 13:54:32 2016
 %% Update Count     : 221
+%% Last Modified On : Tue May  3 08:05:33 2016
+%% Update Count     : 246
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 % requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
 % red highlighting ®...® (registered trademark sumbol)
 % blue highlighting ©...© (copyright symbol)
 % latex escape §...§ (section symbol)
 % keyword escape ¶...¶ (pilcrow symbol)
+% inline code ©...© (copyright symbol) emacs: C-q M-)
+% red highlighting ®...® (registered trademark sumbol) emacs: C-q M-.
+% latex escape §...§ (section symbol) emacs: C-q M-'
+% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
 % math escape $...$ (dollar symbol)
 …
 \CC~\cite{c++,ANSI14:C++} is an example of a similar project;
 however, it largely extended the language, and did not address existing problems.\footnote{%
 Two important existing problems addressed were changing the type of character literals from \lstinline@int@ to \lstinline@char@ and enumerator from \lstinline@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.}
 Fortran~\cite{Fortran08}, Ada~\cite{Ada12}, and Cobol~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features are added and problems fixed within the framework of the existing language.
 Java~\cite{Java8}, Go~\cite{Go}, Rust~\cite{Rust} and D~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
 …
 However, it is necessary to differentiate between C and \CFA code because of name overloading, as for \CC.
 For example, the C math-library provides the following routines for computing the absolute value of the basic type: \lstinline@abs@, \lstinline@labs@, \lstinline@llabs@, \lstinline@fabs@, \lstinline@fabsf@, \lstinline@fabsl@, \lstinline@cabsf@, \lstinline@cabs@, and \lstinline@cabsl@.
 Whereas, \CFA wraps each of these routines into one with the common name \lstinline@abs@.
+For example, the C math-library provides the following routines for computing the absolute value of the basic type: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©.
+Whereas, \CFA wraps each of these routines into one with the common name ©abs©.
 \begin{lstlisting}
 char abs( char );
 …
 long double _Complex abs( long double _Complex );
 \end{lstlisting}
 The problem is the name clash between the library routine \lstinline@abs@ and the \CFA names \lstinline@abs@.
 Hence, names appearing in an \lstinline@extern "C"@ block have \newterm{C linkage}.
+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} 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 ``\lstinline@abs@'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
 Hence, knowing the name \lstinline@abs@ should be sufficient to apply it to any type where it is applicable.
+The 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 \lstinline@cfa@ is used to compile \CFA program(s).
+This command works like the GNU \lstinline@gcc@\index{gcc} command, e.g.:
+\begin{lstlisting}
+cfa [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
+\end{lstlisting}
+\indexc{cfa}\index{compilation!cfa@\lstinline$cfa$}
+By default, \CFA programs having the following \lstinline@gcc@ flags turned on:
+The command ©cfa© is used to compile \CFA program(s).
+This command works like the GNU ©gcc©\index{gcc} command, e.g.:
+\begin{lstlisting}
+cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
+\end{lstlisting}
+By default, \CFA programs having the following ©gcc© flags turned on:
 \begin{description}
 \item\hspace*{-4pt}\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{\lstinline$-std=gnu99$}}
+\item\hspace*{-4pt}\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
 The 1999 C standard plus GNU extensions.
 \item\hspace*{-4pt}\Indexc{-fgnu89-¶inline¶}\index{compilation option!-fgnu89-inline@{\lstinline$-fgnu89-¶inline¶$}}
+\item\hspace*{-4pt}\Indexc{-fgnu89-¶inline¶}\index{compilation option!-fgnu89-inline@{©-fgnu89-¶inline¶©}}
 Use the traditional GNU semantics for inline routines in C99 mode.
 \end{description}
 The following new \CFA option is available:
 \begin{description}
 \item\hspace*{-4pt}\Indexc{-CFA}\index{compilation option!-CFA@{\lstinline$-CFA$}}
+\item\hspace*{-4pt}\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.
 \end{description}
 …
 The following preprocessor variables are available:
 \begin{description}
 \item\hspace*{-4pt}\Indexc{__CFA__}\index{preprocessor variables!__CFA__@{\lstinline$__CFA__$}}
+\item\hspace*{-4pt}\Indexc{__CFA__}\index{preprocessor variables!__CFA__@{©__CFA__©}}
 is always available during preprocessing and its value is the current major \Index{version number} of \CFA.\footnote{
 The C preprocessor allows only integer values in a preprocessor variable so a value like ``\Version'' is not allowed.
 Hence, the need to have three variables for the major, minor and patch version number.}
 \item\hspace*{-4pt}\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{\lstinline$__CFA_MINOR__$}}
+\item\hspace*{-4pt}\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{©__CFA_MINOR__©}}
 is always available during preprocessing and its value is the current minor \Index{version number} of \CFA.
 \item\hspace*{-4pt}\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@\lstinline$__CFA_PATCH__$}
+\item\hspace*{-4pt}\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@©__CFA_PATCH__©}
 is always available during preprocessing and its value is the current patch \Index{version number} of \CFA.
 \item\hspace*{-4pt}\Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@\lstinline$__CFORALL__$}
+\item\hspace*{-4pt}\Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@©__CFORALL__©}
 is always available during preprocessing and it has no value.
 \end{description}
 …
 #endif
 \end{lstlisting}
 which conditionally includes the correct header file, if the program is compiled using \lstinline@gcc@ or \lstinline@cfa@.
+which conditionally includes the correct header file, if the program is compiled using ©gcc© or ©cfa©.
 …
 \begin{enumerate}
 \item
 A sequence of underscores is disallowed, e.g., \lstinline@12__34@ is invalid.
+A sequence of underscores is disallowed, e.g., ©12__34© is invalid.
 \item
 Underscores may only appear within a sequence of digits (regardless of the digit radix).
 In other words, an underscore cannot start or end a sequence of digits, e.g., \lstinline@_1@, \lstinline@1_@ and \lstinline@_1_@ are invalid (actually, the 1st and 3rd examples are identifier names).
+In other words, an underscore cannot start or end a sequence of digits, e.g., ©_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 \lstinline@0@ or hexadecimal \lstinline@0x@ prefix may end with an underscore \lstinline@0_377@ or \lstinline@0x_ff@;
 the exponent infix \lstinline@E@ may start or end with an underscore \lstinline@1.0_E10@, \lstinline@1.0E_10@ or \lstinline@1.0_E_10@;
 the type suffixes \lstinline@U@, \lstinline@L@, etc. may start with an underscore \lstinline@1_U@, \lstinline@1_ll@ or \lstinline@1.0E10_f@.
+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 (most cultures use comma or period among digits for the same purpose).
 …
 C and the new \CFA declarations may appear together in the same program block, but cannot be mixed within a specific declaration.
 In \CFA declarations, the same tokens are used as in C: the character \lstinline@*@ is used to indicate a pointer, square brackets \lstinline@[@\,\lstinline@]@ are used to represent an array, and parentheses \lstinline@()@ are used to indicate a routine parameter.
+In \CFA declarations, the same tokens are used as in C: the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array, and parentheses ©()© are used to indicate a routine parameter.
 However, unlike C, \CFA type declaration tokens are specified from left to right and the entire type specification is distributed across all variables in the declaration list.
 For instance, variables \lstinline@x@ and \lstinline@y@ of type pointer to integer are defined in \CFA as follows:
+For instance, variables ©x© and ©y© of type pointer to integer are defined in \CFA as follows:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 …
 \end{quote2}
 All type qualifiers, i.e., \lstinline@const@ and \lstinline@volatile@, are used in the normal way with the new declarations but appear left to right, e.g.:
+All type qualifiers, i.e., ©const© and ©volatile©, are used in the normal way with the new declarations but appear left to right, e.g.:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
 …
 \end{tabular}
 \end{quote2}
 All declaration qualifiers, i.e., \lstinline@extern@, \lstinline@static@, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
+All declaration qualifiers, i.e., ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} e.g.:
 \begin{quote2}
 …
 \end{quote2}
 Unsupported are K\&R C declarations where the base type defaults to \lstinline@int@, if no type is specified\footnote{
+Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified\footnote{
 At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}},
 e.g.:
 …
 \section{Type Operators}
 The new declaration syntax can be used in other contexts where types are required, e.g., casts and the pseudo-routine \lstinline@sizeof@:
+The new declaration syntax can be used in other contexts where types are required, e.g., casts and the pseudo-routine ©sizeof©:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 …
+}
 \end{lstlisting}
 where routine \lstinline@f@ has three output (return values) and three input parameters.
+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, \lstinline@[]@, 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{
 Michael Tiemann, with help from Doug Lea, provided named return values in g++, circa 1989.}
 The value of each local return variable is automatically returned at routine termination.
 …
 int (*f(x))[ 5 ] int x; {}
 \end{lstlisting}
 The string ``\lstinline@int (*f(x))[ 5 ]@'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``\lstinline@[ 5 ] int x@'' declares a \CFA style parameter x of type array of 5 integers.
 Since the strings overlap starting with the open bracket, \lstinline@[@, there is an ambiguous interpretation for the string.
+The string ``©int (*f(x))[ 5 ]©'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``©[ 5 ] int x©'' declares a \CFA style parameter x of type array of 5 integers.
+Since the strings overlap starting with the open bracket, ©[©, there is an ambiguous interpretation for the string.
 As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity:
 \begin{lstlisting}
 …
 int f( int (* foo) );           // foo is redefined as a parameter name
 \end{lstlisting}
 The string ``\lstinline@int (* foo)@'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
 The redefinition of a type name in a parameter list is the only context in C where the character \lstinline@*@ can appear to the left of a type name, and \CFA relies on all type modifier characters appearing to the right of the type name.
+The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
+The redefinition of a type name in a parameter list is the only context in C where the character ©*© can appear to the left of a type name, and \CFA relies on all type modifier characters appearing to the right of the type name.
 The 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.
 …
 \subsection{Returning Values}
 Named return values handle the case where it is necessary to define a local variable whose value is then returned in a \lstinline@return@ statement, as in:
+Named return values handle the case where it is necessary to define a local variable whose value is then returned in a ©return© statement, as in:
 \begin{lstlisting}
 int f() {
 …
+}
 \end{lstlisting}
 Because the value in the return variable is automatically returned when a \CFA routine terminates, the \lstinline@return@ statement \emph{does not} contain an expression, as in:
+Because the value in the return variable is automatically returned when a \CFA routine terminates, the ©return© statement \emph{does not} contain an expression, as in:
 \begin{lstlisting}
 ®[ int x ]® f() {
 …
+}
 \end{lstlisting}
 When the return is encountered, the current value of \lstinline@x@ is returned to the calling routine.
 As well, ``falling off the end'' of a routine without a \lstinline@return@ statement is permitted, as in:
+When the return is encountered, the current value of ©x© is returned to the calling routine.
+As well, ``falling off the end'' of a routine without a ©return© statement is permitted, as in:
 \begin{lstlisting}
 [ int x ] f() {
 …
 } // implicitly return x
 \end{lstlisting}
 In this case, the current value of \lstinline@x@ is returned to the calling routine just as if a \lstinline@return@ had been encountered.
+In this case, the current value of ©x© is returned to the calling routine just as if a ©return© had been encountered.
 …
 \end{tabular}
 \end{quote2}
 In the left example in C, types \lstinline@C@, \lstinline@U@ and \lstinline@T@ are implicitly hoisted outside of type \lstinline@S@ into the containing block scope.
 In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``\lstinline@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``\lstinline@::@''.
+In the left example in C, types ©C©, ©U© and ©T© are implicitly hoisted outside of type ©S© into the containing block scope.
+In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``©.©'' for type qualification, as does Java, rather than the \CC type-selection operator ``©::©''.
 …
 Nested routines are not first-class, meaning a nested routine cannot be returned if it has references to variables in its enclosing blocks;
 the only exception is references to the external block of the translation unit, as these variables persist for the duration of the program.
 The following program in undefined in \CFA (and \lstinline@gcc@\index{gcc})
+The following program in undefined in \CFA (and ©gcc©\index{gcc})
 \begin{lstlisting}
 [* [int]( int )] foo() {                // int (*foo())( int )
 …
 [ §\emph{exprlist}§ ]
 \end{lstlisting}
 where \lstinline@$\emph{exprlist}$@ is a list of one or more expressions separated by commas.
 The brackets, \lstinline$[]$, allow differentiating between tuples and expressions containing the C comma operator.
+where ©$\emph{exprlist}$© is a list of one or more expressions separated by commas.
+The brackets, ©[]©, allow differentiating between tuples and expressions containing the C comma operator.
 The following are examples of tuples:
 \begin{lstlisting}
 …
 [ v+w, x*y, 3.14159, f() ]
 \end{lstlisting}
 Tuples are permitted to contain sub-tuples (i.e., nesting), such as \lstinline@[ [ 14, 21 ], 9 ]@, which is a 2-element tuple whose first element is itself a tuple.
+Tuples are permitted to contain sub-tuples (i.e., nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.
 Note, a tuple is not a record (structure);
 a record denotes a single value with substructure, whereas a tuple is multiple values with no substructure (see flattening coercion in Section 12.1).
 …
 [ §\emph{typelist}§ ]
 \end{lstlisting}
 where \lstinline@$\emph{typelist}$@ is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
+where ©$\emph{typelist}$© is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
 Examples of tuple types include:
 \begin{lstlisting}
 …
 [ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ]
 \end{lstlisting}
 Like tuples, tuple types may be nested, such as \lstinline@[ [ int, int ], int ]@, which is a 2-element tuple type whose first element is itself a tuple type.
+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:
 …
 tuple does not have structure like a record; a tuple is simply converted into a list of components.
 \begin{rationale}
 The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; i.e., a statement such as \lstinline@g( f() )@ is not supported.
+The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; i.e., a statement such as ©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 \lstinline@[i][j]...@ and not \lstinline@i, j, ...]@.
 Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, e.g., \lstinline@f[g()]@ always means a single subscript value because there is only one set of brackets.
 Fixing this requires a major change to C because the syntactic form \lstinline@M[i, j, k]@ already has a particular meaning: \lstinline@i, j, k@ is a comma expression.
+The C subscript list has the form ©[i][j]...© and not ©[i, j, ...]©.
+Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, e.g., ©f[g()]© always means a single subscript value because there is only one set of brackets.
+Fixing this requires a major change to C because the syntactic form ©M[i, j, k]© already has a particular meaning: ©i, j, k© is a comma expression.
 \end{rationale}
 …
 [ a, b, c, d ] = w
 \end{lstlisting}
 \lstinline@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, i.e., a tuple with one or more components, which are themselves tuples, into a flattened tuple, which is a tuple whose components are not tuples, as in:
 …
 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 \lstinline@[ int, [ int, int ], int ]@ can be coerced, using flattening, into the type \lstinline@[ 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 \lstinline@[ 1, 2, 3, 4 ]@ into the tuple \lstinline@[ 1, [ 2, 3 ], 4 ]@ or the tuple type \lstinline@[ int, int, int, int ]@ into the tuple type \lstinline@[ int, [ int, int ], int ]@.
+For example, structuring the tuple ©[ 1, 2, 3, 4 ]© into the tuple ©[ 1, [ 2, 3 ], 4 ]© or the tuple type ©[ int, int, int, int ]© into the tuple type ©[ int, [ int, int ], int ]©.
 In the following example, the last assignment illustrates all the tuple coercions:
 \begin{lstlisting}
 …
 \end{lstlisting}
 Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values;
 therefore, the right-hand tuple is now the tuple \lstinline@[ [ 1, 2, 3, 4 ], 5 ]@.
 This tuple is then flattened, yielding \lstinline@[ 1, 2, 3, 4, 5 ]@, which is structured into \lstinline@[ 1, [ 2, 3, 4, 5 ] ]@ to match the tuple type of the left-hand side.
 The tuple \lstinline@[ 2, 3, 4, 5 ]@ is then closed to create a tuple value.
 Finally, \lstinline@x@ is assigned \lstinline@1@ and \lstinline@w@ is assigned the tuple value using multiple assignment (see Section 14).
+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.
 …
 \end{lstlisting}
 The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, i.e., any data object that can appear on the left-hand side of a conventional assignment statement.
 \lstinline@$\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{lstlisting}
 The temporary \lstinline@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, \lstinline@y[i]@ uses the previous value of \lstinline@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.
 …
 [ x, y, z ] = [ 1, 2, 3 ];
 \end{lstlisting}
 Here, the values \lstinline@1@, \lstinline@2@ and \lstinline@3@ are assigned, respectively, to the variables \lstinline@x@, \lstinline@y@ and \lstinline@z@.
+Here, the values ©1©, ©2© and ©3© are assigned, respectively, to the variables ©x©, ©y© and ©z©.
  A more complex example is:
 \begin{lstlisting}
 [ i, y[ i ], z ] = [ 1, i, a + b ];
 \end{lstlisting}
 Here, the values \lstinline@1@, \lstinline@i@ and \lstinline@a + b@ are assigned to the variables \lstinline@i@, \lstinline@y[i]@ and \lstinline@z@, respectively.
+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{lstlisting}
 correctly interchanges (swaps) the values stored in \lstinline@x@ and \lstinline@y@.
+correctly interchanges (swaps) the values stored in ©x© and ©y©.
 The following cases are errors:
 \begin{lstlisting}
 …
 §\emph{expr}§ -> [ §\emph{fieldlist}§ ]
 \end{lstlisting}
 \emph{expr} is any expression yielding a value of type record, e.g., \lstinline@struct@, \lstinline@union@.
+\emph{expr} is any expression yielding a value of type record, e.g., ©struct©, ©union©.
 Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}.
 A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is
 …
 also, it is unnecessary to specify all the fields of a struct in a multiple record-field tuple.
 If a field of a \lstinline@struct@ is itself another \lstinline@struct@, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example:
+If a field of a ©struct© is itself another ©struct©, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example:
 \begin{lstlisting}
 struct inner {
 …
 \section{Labelled Break/Continue}
 While C provides \lstinline@break@ and \lstinline@continue@ statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
 Unfortunately, this restriction forces programmers to use \lstinline@goto@ to achieve the equivalent for more than one level of nesting.
 To prevent having to make this switch, the \lstinline@break@ and \lstinline@continue@ are extended with a target label to support static multi-level exit~\cite{Buhr85,Java}.
 For the labelled \lstinline@break@, it is possible to specify which control structure is the target for exit, as in:
+While C provides ©break© and ©continue© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
+Unfortunately, this restriction forces programmers to use ©goto© to achieve the equivalent for more than one level of nesting.
+To prevent having to make this switch, the ©break© and ©continue© are extended with a target label to support static multi-level exit~\cite{Buhr85,Java}.
+For the labelled ©break©, it is possible to specify which control structure is the target for exit, as in:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 …
 \end{quote2}
 The inner most loop has three exit points, which cause termination of one or more of the three nested loops, respectively.
 For the labelled \lstinline@continue@, it is possible to specify which control structure is the target for the next loop iteration, as in:
+For the labelled ©continue©, it is possible to specify which control structure is the target for the next loop iteration, as in:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 …
 \end{quote2}
 The inner most loop has three restart points, which cause the next loop iteration to begin, respectively.
 For both \lstinline@break@ and \lstinline@continue@, the target label must be directly associated with a \lstinline@for@, \lstinline@while@ or \lstinline@do@ statement;
 for \lstinline@break@, the target label can also be associated with a \lstinline@switch@ statement.
 Both \lstinline@break@ and \lstinline@continue@ with target labels are simply a \lstinline@goto@ restricted in the following ways:
+For both ©break© and ©continue©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
+for ©break©, the target label can also be associated with a ©switch© statement.
+Both ©break© and ©continue© with target labels are simply a ©goto© restricted in the following ways:
 \begin{itemize}
 \item
 …
 Since they always transfers out of containing control structures, they cannot be used to branch into a control structure.
 \end{itemize}
 The advantage of the labelled \lstinline@break@/\lstinline@continue@ is that it allows static multi-level exits without having to use the \lstinline@goto@ statement and ties control flow to the target control structure rather than an arbitrary point in a program.
+The advantage of the labelled ©break©/©continue© is that it allows static multi-level exits without having to use the ©goto© statement and ties control flow to the target control structure rather than an arbitrary point in a program.
 Furthermore, the location of the label at the beginning of the target control structure informs the reader that complex control-flow is occurring in the body of the control structure.
 With \lstinline@goto@, the label at the end of the control structure fails to convey this important clue early enough to the reader.
+With ©goto©, the label at the end of the control structure fails to convey this important clue early enough to the reader.
 Finally, using an explicit target for the transfer instead of an implicit target allows new nested loop or switch constructs to be added or removed without affecting other constructs.
 The implicit targets of the current \lstinline@break@ and \lstinline@continue@, i.e., the closest enclosing loop or \lstinline@switch@, change as certain constructs are added or removed.
+The implicit targets of the current ©break© and ©continue©, i.e., the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
 \section{Switch Statement}
 C allows a number of questionable forms for the \lstinline@switch@ statement:
+C allows a number of questionable forms for the ©switch© statement:
 \begin{enumerate}
 \item
 By default, the end of a \lstinline@case@ clause\footnote{
 In this section, the term \emph{case clause} refers to either a \lstinline@case@ or \lstinline@default@ clause.}
 \emph{falls through} to the next \lstinline@case@ clause in the \lstinline@switch@ statement;
 to exit a \lstinline@switch@ statement from a \lstinline@case@ clause requires explicitly terminating the clause with a transfer statement, most commonly \lstinline@break@, as in:
+By default, the end of a ©case© clause\footnote{
+In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
+\emph{falls through} to the next ©case© clause in the ©switch© statement;
+to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©, as in:
 \begin{lstlisting}
 switch ( i ) {
 …
 \end{lstlisting}
 In this example, case 2 is always done if case 3 is done.
 This control flow is difficult to simulate with if statements or a \lstinline@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, as in:
 \begin{lstlisting}
 …
 \end{lstlisting}
 However, this situation is handled in other languages without fall-through by allowing a list of case values.
 While fall-through itself is not a problem, the problem occurs when fall-through is the \lstinline@default@, as this semantics is not intuitive to most programmers and is different from virtually all other programming languages with a \lstinline@switch@ statement.
 Hence, \lstinline@default@ fall-through semantics results in a large number of programming errors as programmers often forget the \lstinline@break@ statement at the end of a \lstinline@case@ clause, resulting in inadvertent fall-through.
 \item
 It is possible to place \lstinline@case@ clauses on statements nested \emph{within} the body of the \lstinline@switch@ statement, as in:
+While fall-through itself is not a problem, the problem occurs when fall-through is the ©default©, as this semantics is not intuitive to most programmers and is different from virtually all other programming languages with a ©switch© statement.
+Hence, ©default© fall-through semantics results in a large number of programming errors as programmers often forget the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
+\item
+It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement, as in:
 \begin{lstlisting}
 switch ( i ) {
 …
+}
 \end{lstlisting}
 which unrolls a loop N times (N = 8 above) and uses the \lstinline@switch@ statement to deal with any iterations not a multiple of N.
+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 \lstinline@default@ clause anywhere in the list of labelled clauses for a \lstinline@switch@ statement, rather than only at the end.
 Virtually all programming languages with a \lstinline@switch@ statement require the \lstinline@default@ clause to appear last in the case-clause list.
 The logic for this semantics is that after checking all the \lstinline@case@ clauses without success, the \lstinline@default@ clause is selected;
 hence, physically placing the \lstinline@default@ clause at the end of the \lstinline@case@ clause list matches with this semantics.
 This physical placement can be compared to the physical placement of an \lstinline@else@ clause at the end of a series of connected \lstinline@if@/\lstinline@else@ statements.
 \item
 It is possible to place unreachable code at the start of a \lstinline@switch@ statement, as in:
+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{lstlisting}
 switch ( x ) {
 …
+}
 \end{lstlisting}
 While the declaration of the local variable \lstinline@y@ is useful and its scope is across all \lstinline@case@ clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
 Furthermore, any statements before the first \lstinline@case@ clause can only be executed if labelled and transfered to using a \lstinline@goto@, either from outside or inside of the \lstinline@switch@.
+While the declaration of the local variable ©y© is useful and its scope is across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
+Furthermore, any statements before the first ©case© clause can only be executed if labelled and transfered to using a ©goto©, either from outside or inside of the ©switch©.
 As mentioned, transfer into control structures should be forbidden.
 Transfers from within the \lstinline@switch@ body using a \lstinline@goto@ are equally unpalatable.
+Transfers from within the ©switch© body using a ©goto© are equally unpalatable.
 \end{enumerate}
 Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
 \begin{itemize}
 \item
 the number of \lstinline@switch@ statements is small,
 \item
 most \lstinline@switch@ statements are well formed (i.e., no Duff's device),
 \item
 the \lstinline@default@ clause is usually written as the last case-clause,
 \item
 and there is only a medium amount of fall-through from one \lstinline@case@ clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
+the number of ©switch© statements is small,
+\item
+most ©switch© statements are well formed (i.e., no Duff's device),
+\item
+the ©default© clause is usually written as the last case-clause,
+\item
+and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
 \end{itemize}
 These observations should help to put the effects of suggested changes into perspective.
 …
 \begin{enumerate}
 \item
 Eliminating the \lstinline@default@ fall-through problem has the greatest potential for affecting existing code.
 However, even if fall-through is removed, most \lstinline@switch@ statements would continue to work because of the explicit transfers already present at the end of each \lstinline@case@ clause, and the common placement of the \lstinline@default@ clause at the end of the case list.
 In addition, the above grammar provides for the most common use of fall-through, i.e., a list of \lstinline@case@ clauses executing common code, e.g.:
+Eliminating the ©default© fall-through problem has the greatest potential for affecting existing code.
+However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, and the common placement of the ©default© clause at the end of the case list.
+In addition, the above grammar provides for the most common use of fall-through, i.e., a list of ©case© clauses executing common code, e.g.:
 \begin{lstlisting}
 case 1:  case 2:  case 3: ...
 \end{lstlisting}
 Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of \lstinline@switch@ statement, called \lstinline@choose@, with no fall-through semantics.
 The \lstinline@choose@ statement is identical to the new \lstinline@switch@ statement, except there is no implicit fall-through between case-clauses and the \lstinline@break@ statement applies to the enclosing loop construct (as for the continue statement in a \lstinline@switch@ statement).
+Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no fall-through semantics.
+The ©choose© statement is identical to the new ©switch© statement, except there is no implicit fall-through between case-clauses and the ©break© statement applies to the enclosing loop construct (as for the continue statement in a ©switch© statement).
 It is still possible to fall-through if a case-clause ends with the new keyword fallthru, e.g.:
 \begin{lstlisting}
 …
 \item
 Eliminating Duff's device is straightforward and only invalidates a small amount of very questionable code.
 The solution is to allow \lstinline@case@ clauses to only appear at the same nesting level as the \lstinline@switch@ body, as is done in most other programming languages with \lstinline@switch@ statements.
 \item
 The issue of \lstinline@default@ at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the \lstinline@default@ clause may appear is locations other than at the end.
+The solution is to allow ©case© clauses to only appear at the same nesting level as the ©switch© body, as is done in most other programming languages with ©switch© statements.
+\item
+The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause may appear is locations other than at the end.
 Therefore, no language change is made for this issue.
 \item
 Dealing with unreachable code at the start of a \lstinline@switch@ statement is solved by defining the declaration-list, including any associated initialization, at the start of a \lstinline@switch@ statement body to be executed before the transfer to the appropriate \lstinline@case@ clause.
+Dealing with unreachable code at the start of a ©switch© statement is solved by defining the declaration-list, including any associated initialization, at the start of a ©switch© statement body to be executed before the transfer to the appropriate ©case© clause.
 This semantics is the same as for declarations at the start of a loop body, which are executed before each iteration of the loop body.
 As well, this grammar does not allow statements to appear before the first \lstinline@case@ clause.
+As well, this grammar does not allow statements to appear before the first ©case© clause.
 The change is compatible for declarations with initialization in this context because existing code cannot assume the initialization has occurred.
 The change is incompatible for statements, but any existing code using it is highly questionable, as in:
 …
+}
 \end{lstlisting}
 The statement after the \lstinline@switch@ can never be executed unless it is labelled.
 If it is labelled, it must be transfered to from outside or inside the \lstinline@switch@ statement, neither of which is acceptable control flow.
+The statement after the ©switch© can never be executed unless it is labelled.
+If it is labelled, it must be transfered to from outside or inside the ©switch© statement, neither of which is acceptable control flow.
 \end{enumerate}
 …
 \section{Case Clause}
 C restricts the \lstinline@case@ clause of a \lstinline@switch@ statement to a single value.
 For multiple \lstinline@case@ clauses associated with the same statement, it is necessary to have multiple \lstinline@case@ clauses rather than multiple values.
 Requiring a \lstinline@case@ clause for each value does not seem to be in the spirit of brevity normally associated with C.
 Therefore, the \lstinline@case@ clause is extended with a list of values, as in:
+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{30pt}}l@{\hspace{20pt}}l@{}}
 …
 The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.
 Use \lstinline@&@ to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
+Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
 When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
 The \lstinline@&@ is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.
+The ©&© is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.
 \begin{figure}
 …
 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 \lstinline@&&@, \lstinline@||@, and \lstinline@!@ can be applied to any scalar arguments and are defined in terms of comparison against 0 (ex. \lstinline@(a && b)@ becomes \lstinline@(a != 0 && b != 0)@).
+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
 …
 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 \lstinline@_Bool@.
+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
 \lstinline@?[?]@ & subscripting \impl{?[?]}\\
 \lstinline@?()@ & function call \impl{?()}\\
 \lstinline@?++@ & postfix increment \impl{?++}\\
 \lstinline@?--@ & postfix decrement \impl{?--}\\
 \lstinline@++?@ & prefix increment \impl{++?}\\
 \lstinline@--?@ & prefix decrement \impl{--?}\\
 \lstinline@*?@ & dereference \impl{*?}\\
 \lstinline@+?@ & unary plus \impl{+?}\\
 \lstinline@-?@ & arithmetic negation \impl{-?}\\
 \lstinline@~?@ & bitwise negation \impl{~?}\\
 \lstinline@!?@ & logical complement \impl{"!?}\\
 \lstinline@?*?@ & multiplication \impl{?*?}\\
 \lstinline@?/?@ & division \impl{?/?}\\
+©?[?]© & 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
 \lstinline@?%?@ & remainder \impl{?%?}\\
 \lstinline@?+?@ & addition \impl{?+?}\\
 \lstinline@?-?@ & subtraction \impl{?-?}\\
 \lstinline@?<<?@ & left shift \impl{?<<?}\\
 \lstinline@?>>?@ & right shift \impl{?>>?}\\
 \lstinline@?<?@ & less than \impl{?<?}\\
 \lstinline@?<=?@ & less than or equal \impl{?<=?}\\
 \lstinline@?>=?@ & greater than or equal \impl{?>=?}\\
 \lstinline@?>?@ & greater than \impl{?>?}\\
 \lstinline@?==?@ & equality \impl{?==?}\\
 \lstinline@?!=?@ & inequality \impl{?"!=?}\\
 \lstinline@?&?@ & bitwise AND \impl{?&?}\\
+©?%?© & 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
 \lstinline@?^?@ & exclusive OR \impl{?^?}\\
 \lstinline@?|?@ & inclusive OR \impl{?"|?}\\
 \lstinline@?=?@ & simple assignment \impl{?=?}\\
 \lstinline@?*=?@ & multiplication assignment \impl{?*=?}\\
 \lstinline@?/=?@ & division assignment \impl{?/=?}\\
 \lstinline@?%=?@ & remainder assignment \impl{?%=?}\\
 \lstinline@?+=?@ & addition assignment \impl{?+=?}\\
 \lstinline@?-=?@ & subtraction assignment \impl{?-=?}\\
 \lstinline@?<<=?@ & left-shift assignment \impl{?<<=?}\\
 \lstinline@?>>=?@ & right-shift assignment \impl{?>>=?}\\
 \lstinline@?&=?@ & bitwise AND assignment \impl{?&=?}\\
 \lstinline@?^=?@ & exclusive OR assignment \impl{?^=?}\\
 \lstinline@?|=?@ & inclusive OR assignment \impl{?"|=?}\\
+©?^?© & 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, \lstinline@a + b@ becomes \lstinline@?+?(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.
 …
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}ll@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CC}}        & \multicolumn{1}{c}{\lstinline@gcc@}\index{gcc} \\
+\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CC}}        & \multicolumn{1}{c}{©gcc©}\index{gcc} \\
 \begin{lstlisting}
 …
 \end{itemize}
 In \CFA, \lstinline@typedef@ provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
 \lstinline@gcc@ provides \lstinline@typeof@ to declare a secondary variable from a primary variable.
+In \CFA, ©typedef© provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
+©gcc© provides ©typeof© to declare a secondary variable from a primary variable.
 \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, \lstinline@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{lstlisting}
 auto j = ®...®
 \end{lstlisting}
 and the need to write a routine to compute using \lstinline@j@
+and the need to write a routine to compute using ©j©
 \begin{lstlisting}
 void rtn( ®...® parm );
 rtn( j );
 \end{lstlisting}
 A programmer must work backwards to determine the type of \lstinline@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 \lstinline@typedef@ and \lstinline@typeof@ in \CFA, and the strong need to use the type of left-hand side in inferencing, auto type-inferencing is not supported at this time.
+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.
 …
 } s;
 \end{lstlisting}
 The problem occurs in accesing these fields using the selection operation ``\lstinline@.@'':
+The problem occurs in accesing these fields using the selection operation ``©.©'':
 \begin{lstlisting}
 s.0 = 0;        // ambiguity with floating constant .0
 …
 \end{lstlisting}
 While this sytact is awkward, it is unlikely many programers will name fields of a structure 0 or 1.
 Like the \CC lexical problem with closing template-syntax, e.g, \lstinline@Foo<Bar<int®>>®@, this issue can be solved with a more powerful lexer/parser.
 There are several ambiguous cases with operator identifiers, e.g., \lstinline@int *?*?()@, where the string \lstinline@*?*?@ can be lexed as \lstinline@*@/\lstinline@?*?@ or \lstinline@*?@/\lstinline@*?@.
 Since it is common practise to put a unary operator juxtaposed to an identifier, e.g., \lstinline@*i@, users will be annoyed if they cannot do this with respect to operator identifiers.
+Like the \CC lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser.
+There are several ambiguous cases with operator identifiers, e.g., ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©.
+Since it is common practise to put a unary operator juxtaposed to an identifier, e.g., ©*i©, users will be annoyed if they cannot do this with respect to operator identifiers.
 Even with this special hack, there are 5 general cases that cannot be handled.
 The first case is for the function-call identifier \lstinline@?()@:
+The first case is for the function-call identifier ©?()©:
 \begin{lstlisting}
 int *§\textvisiblespace§?()();  // declaration: space required after '*'
 *§\textvisiblespace§?()();              // expression: space required after '*'
 \end{lstlisting}
 Without the space, the string \lstinline@*?()@ is ambiguous without N character look ahead;
 it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument/parameter list.
+Without the space, the string ©*?()© is ambiguous without N character look ahead;
+it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list.
 The 4 remaining cases occur in expressions:
 …
 i§\textvisiblespace§?--i:0;             // space required after '?'
 \end{lstlisting}
 In the first two cases, the string \lstinline@i++?@ is ambiguous, where this string can be lexed as \lstinline@i@ / \lstinline@++?@ or \lstinline@i++@ / \lstinline@?@;
 it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument list.
 In the second two cases, the string \lstinline@?++x@ is ambiguous, where this string can be lexed as \lstinline@?++@ / \lstinline@x@ or \lstinline@?@ / y\lstinline@++x@;
 it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument list.
+In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©;
+it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
+In the second two cases, the string ©?++x© is ambiguous, where this string can be lexed as ©?++© / ©x© or ©?© / y©++x©;
+it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
 …
 \begin{enumerate}
 \item
 Change type of character literal \lstinline@int@ to \lstinline@char@.
+Change type of character literal ©int© to ©char©.
 This change allows overloading differentiation argument type matching, e.g.:
 \begin{lstlisting}
 …
 \item
 Change: String literals made \lstinline@const@ \\
 The type of a string literal is changed from \lstinline@array of char@ to \lstinline@array of const char@.
 The type of a wide string literal is changed from \lstinline@array of wchar_t@ to \lstinline@array of const wchar_t@. \\
+Change: String literals made ©const© \\
+The type of a string literal is changed from ©array of char© to ©array of const char©.
+The type of a wide string literal is changed from ©array of wchar_t© to ©array of const wchar_t©. \\
 Rationale: This avoids calling an inappropriate overloaded function, which might expect to be able to modify its argument.
 Effect on original feature: Change to semantics of well-defined feature. \\
 Difficulty of converting: Simple syntactic transformation, because string literals can be converted to \lstinline@char*;@ (4.2).
+Difficulty of converting: Simple syntactic transformation, because string literals can be converted to ©char*;© (4.2).
 The most common cases are handled by a new but deprecated standard conversion:
 \begin{lstlisting}
 …
 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC.
 Nested types are not hoisted and can be referenced using the field selection operator ``\lstinline@.@'', unlike the \CC scope-resolution operator ``\lstinline@::@''.
+Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
 Given that nested types in C are equivalent to not using them, i.e., they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.
 …
 %$
 \item
 A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline@,.:;!?)]}%¢»@
+A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.:;!?)]}%¢»©
 \begin{lstlisting}[belowskip=0pt]
 sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | ") x" | 8 | "] x" | 9 | "} x"

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

Context Navigation

Changeset 0638c44 for doc/user/user.tex

Legend:

doc/user/user.tex

Download in other formats: