Context Navigation

← Previous Change
Next Change →

user.tex

Timestamp:

Jul 4, 2017, 9:40:16 AM (8 years ago)

Author:

Rob Schluntz <rschlunt@…>

Branches:

ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc

Children:

208e5be

Parents:

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

Message:

Merge branch 'master' into references

File:

: 1 edited

doc/user/user.tex (modified) (116 diffs)

Legend:

: Unmodified
: Added
: Removed

doc/user/user.tex

-              r9c951e3
+              rb1e63ac5
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Mon May 15 18:29:58 2017
 %% Update Count     : 1598
+%% Last Modified On : Fri Jun 16 12:00:01 2017
+%% Update Count     : 2433
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \usepackage[pagewise]{lineno}
 \renewcommand{\linenumberfont}{\scriptsize\sffamily}
 \input{common}                                          % bespoke macros used in the document
+\input{common}                                          % common CFA document macros
 \usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
 \usepackage{breakurl}
 …
 \author{
 \huge \CFA Team \medskip \\
 \Large Peter A. Buhr, Richard Bilson, Thierry Delisle, \smallskip \\
+\Large Andrew Beach, Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\
 \Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Rob Schluntz
 }% author
 …
 \renewcommand{\subsectionmark}[1]{\markboth{\thesubsection\quad #1}{\thesubsection\quad #1}}
 \pagenumbering{roman}
 \linenumbers                                            % comment out to turn off line numbering
+%\linenumbers                                            % comment out to turn off line numbering
 \maketitle
 …
 \CFA{}\index{cforall@\CFA}\footnote{Pronounced ``\Index*{C-for-all}'', and written \CFA, CFA, or \CFL.} is a modern general-purpose programming-language, designed as an evolutionary step forward for the C programming language.
 The syntax of the \CFA language builds from C, and should look immediately familiar to C/\Index*[C++]{\CC} programmers.
 % Any language feature that is not described here can be assumed to be using the standard C11 syntax.
+The syntax of the \CFA language builds from C, and should look immediately familiar to C/\Index*[C++]{\CC{}} programmers.
+% Any language feature that is not described here can be assumed to be using the standard \Celeven syntax.
 \CFA adds many modern programming-language features that directly lead to increased \emph{\Index{safety}} and \emph{\Index{productivity}}, while maintaining interoperability with existing C programs and achieving C performance.
 Like C, \CFA is a statically typed, procedural language with a low-overhead runtime, meaning there is no global \Index{garbage-collection}, but \Index{regional garbage-collection}\index{garbage collection!regional} is possible.
+Like C, \CFA is a statically typed, procedural language with a low-overhead runtime, meaning there is no global \Index{garbage-collection}, but \Index{regional garbage-collection}\index{garbage-collection!regional} is possible.
 The primary new features include parametric-polymorphic routines and types, exceptions, concurrency, and modules.
 …
 instead, a programmer evolves an existing C program into \CFA by incrementally incorporating \CFA features.
 New programs can be written in \CFA using a combination of C and \CFA features.
 \Index*[C++]{\CC} had a similar goal 30 years ago, but currently has the disadvantages of multiple legacy design-choices that cannot be updated and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
+\Index*[C++]{\CC{}} had a similar goal 30 years ago, but currently has the disadvantages of multiple legacy design-choices that cannot be updated and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
 In contrast, \CFA has 30 years of hindsight and a clean starting point.
 Like \Index*[C++]{\CC}, there may be both an old and new ways to achieve the same effect.
 For example, the following programs compare the \CFA and C I/O mechanisms.
+Like \Index*[C++]{\CC{}}, there may be both an old and new ways to achieve the same effect.
+For example, the following programs compare the \CFA, C, and \CC I/O mechanisms, where the programs output the same result.
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{1.5em}}l@{\hspace{1.5em}}l@{}}
 \multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{\CFA}}      & \multicolumn{1}{c}{\textbf{C}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
 \begin{cfa}
 #include <fstream>
+#include <fstream>§\indexc{fstream}§
 int main( void ) {
 …
+&
 \begin{lstlisting}
 #include <stdio.h>
+#include <stdio.h>§\indexc{stdio.h}§
 int main( void ) {
 …
+&
 \begin{lstlisting}
 #include <iostream>
+#include <iostream>§\indexc{iostream}§
 using namespace std;
 int main() {
 …
 \end{tabular}
 \end{quote2}
+The programs output the same result.
+While the \CFA I/O looks similar to the \Index*[C++]{\CC} output style, there are important differences, such as automatic spacing between variables as in \Index*{Python} (see~\VRef{s:IOLibrary}).
+This document is a user manual for the \CFA programming language, targeted at \CFA programmers.
+While the \CFA I/O looks similar to the \Index*[C++]{\CC{}} output style, there are important differences, such as automatic spacing between variables as in \Index*{Python} (see~\VRef{s:IOLibrary}).
+This document is a programmer reference-manual for the \CFA programming language.
+The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of each feature.
+The manual does not teach programming, i.e., how to combine the new constructs to build complex programs.
+A reader should already have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented as well as some experience programming in C/\CC.
 Implementers may refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
-In its current state, this document covers the intended core features of the language.
 Changes to the syntax and additional features are expected to be included in later revisions.
 …
 Even with all its problems, C continues to be popular because it allows writing software at virtually any level in a computer system without restriction.
 For system programming, where direct access to hardware and dealing with real-time issues is a requirement, C is usually the language of choice.
 The TIOBE index~\cite{TIOBE} for March 2016 showed the following programming-language popularity: \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC} 6.7\%, \Csharp 4.3\%, \Index*{Python} 4.3\%, where the next 50 languages are less than 3\% each with a long tail.
+The TIOBE index~\cite{TIOBE} for March 2016 showed the following programming-language popularity: \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC{}} 6.7\%, \Csharp 4.3\%, \Index*{Python} 4.3\%, where the next 50 languages are less than 3\% each with a long tail.
 As well, for 30 years, C has been the number 1 and 2 most popular programming language:
 \begin{center}
 …
 As stated, the goal of the \CFA project is to engineer modern language features into C in an evolutionary rather than revolutionary way.
 \CC~\cite{c++,ANSI14:C++} is an example of a similar project;
+\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.}
 …
 These costs can be prohibitive for many companies with a large software base in C/\CC, and a significant number of programmers requiring retraining to a new programming language.
 The result of this project is a language that is largely backwards compatible with \Index*{C11}~\cite{C11}, but fixing some of the well known C problems and containing many modern language features.
+The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixing some of the well known C problems and containing many modern language features.
 Without significant extension to the C programming language, it is becoming unable to cope with the needs of modern programming problems and programmers;
 as a result, it will fade into disuse.
 Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language.
 While \Index*{C11} made a few simple extensions to the language, nothing was added to address existing problems in the language or to augment the language with modern language features.
+While \Index*[C11]{\Celeven{}} made a few simple extensions to the language, nothing was added to address existing problems in the language or to augment the language with modern language features.
 While some may argue that modern language features may make C complex and inefficient, it is clear a language without modern capabilities is insufficient for the advanced programming problems existing today.
 …
 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.
+% extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC{}} approach of object-oriented extensions.
 \CFA{}\hspace{1pt}'s polymorphism was originally formalized by Ditchfiled~\cite{Ditchfield92}, and first implemented by Bilson~\cite{Bilson03}.
 However, at that time, there was little interesting in extending C, so work did not continue.
 …
 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 nmemb, size_t size,
+void * bsearch( const void * key, const void * base, size_t dim, size_t size,
                                 int (* compar)( const void *, const void * ));
 …
 The 1999 C standard plus GNU extensions.
 \item
+{\lstset{deletekeywords={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.
+}%
 \end{description}
 The following new \CFA options are available:
 …
 \begin{cfa}
 #ifndef __CFORALL__
 #include <stdio.h>                                              §\C{// C header file}§
+#include <stdio.h>§\indexc{stdio.h}§    §\C{// C header file}§
 #else
 #include <fstream>                                              §\C{// \CFA header file}§
+#include <fstream>§\indexc{fstream}§    §\C{// \CFA header file}§
 #endif
 \end{cfa}
 …
 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).
+It is significantly easier to read and enter long constants when they are broken up into smaller groupings (many cultures use comma and/or period among digits for the same purpose).
 This extension is backwards compatible, matches with the use of underscore in variable names, and appears in \Index*{Ada} and \Index*{Java} 8.
 …
 \begin{cfa}
 int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
 double ®`®choose®`® = 3.5;
 \end{cfa}
 Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to a  non-keyword name.
+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©:
 …
 // include file uses the CFA keyword "otype".
 #if ! defined( otype )                  §\C{// nesting ?}§
 #define otype `otype`
+#define otype ®`®otype®`®               §\C{// make keyword an identifier}§
 #define __CFA_BFD_H__
 #endif // ! otype
 …
 \begin{tabular}{@{}ll@{}}
 \begin{cfa}
 int *x[5]
+int * x[5]
 \end{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{}§
+... (*f())[3] += 1;
+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}).
 …
 \CFA provides its own type, variable and routine declarations, using a different syntax.
 The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
 In the following example, \R{red} is for the base type and \B{blue} is for the qualifiers.
 The \CFA declarations move the qualifiers to the left of the base type, i.e., move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
+In the following example, \R{red} is the base type and \B{blue} is qualifiers.
+The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 …
 \end{tabular}
 \end{quote2}
 The only exception is bit field specification, which always appear to the right of the base type.
+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.
 However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
 …
 \begin{cfa}
 int z[ 5 ];
 char *w[ 5 ];
 double (*v)[ 5 ];
+char * w[ 5 ];
+double (* v)[ 5 ];
 struct s {
         int f0:3;
         int *f1;
         int *f2[ 5 ]
+        int * f1;
+        int * f2[ 5 ]
 };
 \end{cfa}
 …
 \begin{cfa}
 int extern x[ 5 ];
 const int static *y;
+const int static * y;
 \end{cfa}
+&
 …
 \end{quote2}
+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}}
+\eg:
+\begin{cfa}
+x;                                                              §\C{// int x}§
+*y;                                                             §\C{// int *y}§
+f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
+f( p1, p2 ) {}                                  §\C{// int f( int p1, int p2 ) {}}§
+\end{cfa}
+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®);
+\end{cfa}
+&
+\begin{cfa}
+y = (®int *®)x;
+i = sizeof(®int * [ 5 ]®);
+\end{cfa}
+\end{tabular}
+\end{quote2}
 Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
 …
 \section{Pointer / Reference}
+\section{Pointer/Reference}
 C provides a \newterm{pointer type};
 \CFA adds a \newterm{reference type}.
+Both types contain an \newterm{address}, which is normally a location in memory.
+Special addresses are used to denote certain states or access co-processor memory.
+By convention, no variable is placed at address 0, so addresses like 0, 1, 2, 3 are often used to denote no-value or other special states.
+Often dereferencing a special state causes a \Index{memory fault}, so checking is necessary during execution.
+If the programming language assigns addresses, a program's execution is \Index{sound}, i.e., all addresses are to valid memory locations.
+C allows programmers to assign addresses, so there is the potential for incorrect addresses, both inside and outside of the computer address-space.
+Program variables are implicit pointers to memory locations generated by the compiler and automatically dereferenced, as in:
+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{
+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.}
+An address is \newterm{sound}, if it points to a valid memory location in scope, \ie within the program's execution-environment and has not been freed.
+Dereferencing an \newterm{unsound} address, including the null pointer, is \Index{undefined}, often resulting in a \Index{memory fault}.
+A program \newterm{object} is a region of data storage in the execution environment, the contents of which can represent values.
+In most cases, objects are located in memory at an address, and the variable name for an object is an implicit address to the object generated by the compiler and automatically dereferenced, as in:
 \begin{quote2}
 \begin{tabular}{@{}lll@{}}
+\begin{tabular}{@{}ll@{\hspace{2em}}l@{}}
 \begin{cfa}
 int x;
 …
 \end{quote2}
 where the right example is how the compiler logically interprets the variables in the left example.
+Since a variable name only points to one location during its lifetime, it is an \Index{immutable} \Index{pointer};
+hence, variables ©x© and ©y© are constant pointers in the compiler interpretation.
+In general, variable addresses are stored in instructions instead of loaded independently, so an instruction fetch implicitly loads a variable's address.
+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.
+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:
 \begin{quote2}
 \begin{tabular}{@{}l|l@{}}
+\multicolumn{1}{c|}{explicit variable address} & \multicolumn{1}{c}{implicit variable address} \\
+\hline
 \begin{cfa}
 lda             r1,100                  // load address of x
 ld              r2,(r1)                   // load value of x
+ld               r2,(r1)                  // load value of x
 lda             r3,104                  // load address of y
 st              r2,(r3)                   // store x into y
+st               r2,(r3)                  // store x into y
 \end{cfa}
+&
 …
 \end{tabular}
 \end{quote2}
 Finally, the immutable nature of a variable's address and the fact that there is no storage for a variable address means pointer assignment\index{pointer!assignment}\index{assignment!pointer} is impossible.
 Therefore, the expression ©x = y© only has one meaning, ©*x = *y©, i.e., manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of instruction decoding.
 A \Index{pointer}/\Index{reference} is a generalization of a variable name, i.e., a mutable address that can point to more than one memory location during its lifetime.
 (Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime and may not occupy storage as the literal is embedded directly into instructions.)
+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}.
+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.
+(Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime, and like a variable name, may not occupy storage if the literal is embedded directly into instructions.)
 Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg:
 \begin{quote2}
 \begin{tabular}{@{}ll@{}}
+\begin{tabular}{@{}l@{\hspace{2em}}l@{}}
 \begin{cfa}
 int x, y, ®*® p1, ®*® p2, ®**® p3;
 …
 \end{cfa}
+&
 \raisebox{-0.45\totalheight}{\input{pointer2.pstex_t}}
+\raisebox{-0.5\totalheight}{\input{pointer2.pstex_t}}
 \end{tabular}
 \end{quote2}
+Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location.
+In many cases, a compiler might be able to infer the meaning:
+Notice, an address has a \Index{duality}\index{address!duality}: a location in memory or the value at that location.
+In many cases, a compiler might be able to infer the best meaning for these two cases.
+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}
 because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
+\Index*{Algol68}~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage.
+However, in C, the following cases are ambiguous, especially with pointer arithmetic:
+\begin{cfa}
+p1 = p2;                                                §\C{// p1 = p2\ \ or\ \ *p1 = *p2}§
+p1 = p1 + 1;                                    §\C{// p1 = p1 + 1\ \ or\ \ *p1 = *p1 + 1}§
+\end{cfa}
+Most languages pick one meaning as the default and the programmer explicitly indicates the other meaning to resolve the address-duality ambiguity\index{address! ambiguity}.
+In C, the default meaning for pointers is to manipulate the pointer's address and the pointed-to value is explicitly accessed by the dereference operator ©*©.
+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}§
 *p1 = *p1 + 1;                                  §\C{// pointed-to value assignment / operation}§
 \end{cfa}
 which works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
+®*®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 switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} denoted by ©&©.
+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;
 …
 Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
 Hence, a reference behaves like the variable name for the current variable it is pointing-to.
+The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, \eg:
+\begin{cfa}
+r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);
+\end{cfa}
+is rewritten as:
+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.\footnote{
+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.
 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}}
 Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}):
 \begin{cfa}
 (&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving variable r1 not variable pointed-to by r1}§
+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}§
 \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 of r2, (\&(\&*)*) cancel giving variable r3}§
+\end{cfa}
+Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses.
+(&(&®*®)®*®)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.
+Fundamentally, pointer and reference objects are functionally interchangeable because both contain addresses.
 \begin{cfa}
 int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
 …
 &&&r3 = p3;                                             §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
 \end{cfa}
+Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one.
+That is, all implicit dereferencing and any cancellation is carried out prior to the start of the program, so reference performance is equivalent to pointer performance.
+A programmer selects a pointer or reference type solely on whether the address is dereferenced frequently or infrequently, which dictates the amount of direct aid from the compiler;
+otherwise, everything else is equal.
+Interestingly, \Index*[C++]{\CC} deals with the address duality by making the pointed-to value the default, and prevent\-ing changes to the reference address, which eliminates half of the duality.
+\Index*{Java} deals with the address duality by making address assignment the default and requiring field assignment (direct or indirect via methods), i.e., there is no builtin bit-wise or method-wise assignment, which eliminates half of the duality.
+As for a pointer, a reference 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, \CC reference}§
+®&®rc = &x;                                             §\C{// error, cannot change rc}§
+const int & const crc = cx;             §\C{// must be initialized, \CC reference}§
+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 ©0© unless an arbitrary pointer is assigned to the reference}, \eg:
+\begin{cfa}
+int & const r = *0;                             §\C{// where 0 is the int * zero}§
+\end{cfa}
+Otherwise, the compiler is managing the addresses for type ©& const© not the programmer, and by a programming discipline of only using references with references, address errors can be prevented.
+Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
+Furthermore, both types are equally performant, as the same amount of dereferencing occurs for both types.
+Therefore, the choice between them is based solely on whether the address is dereferenced frequently or infrequently, which dictates the amount of implicit dereferencing aid from the compiler.
+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}§
+\end{cfa}
+Note, constant reference-types do not prevent \Index{addressing errors} because of explicit storage-management:
+\begin{cfa}
+int & const cr = *malloc();
+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;
 \CFA-style declarations attempt to address this issue:
+\CFA-style declarations (see \VRef{s:Declarations}) attempt to address this issue:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 …
 \end{tabular}
 \end{quote2}
+where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}).
+where the \CFA declaration is read left-to-right.
+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}.
+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.}
+\Index*{Java}'s reference types to objects (all Java objects are on the heap) are like C pointers, which always manipulate the address, and there is no (bit-wise) object assignment, so objects are explicitly cloned by shallow or deep copying, which eliminates half of the address duality.
+\subsection{Initialization}
 \Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage of an object.
 There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding.
+For reference initialization (like pointer), the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}).
+\begin{cfa}
+int * p = &x;                                   §\C{// both \&x and x are possible interpretations}§
+int & r = x;                                    §\C{// x unlikely interpretation, because of auto-dereferencing}§
+\end{cfa}
+Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression.
+Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator.
+\begin{cfa}
+int & f( int & rp );                    §\C{// reference parameter and return}§
+z = f( x ) + f( y );                    §\C{// reference operator added, temporaries needed for call results}§
+\end{cfa}
+Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©rp© can be locally reassigned within ©f©.
+Since ©?+?© takes its arguments by value, the references returned from ©f© are used to initialize compiler generated temporaries with value semantics that copy from the references.
+Because the object being initialized has no value, there is only one meaningful semantics with respect to address duality: it must mean address as there is no pointed-to value.
+In contrast, the left-hand side of assignment has an address that has a duality.
+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).
+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.
+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.
+\begin{cfa}
+int temp1 = f( x ), temp2 = f( y );
+z = temp1 + temp2;
+\end{cfa}
+This \Index{implicit referencing} is crucial for reducing the syntactic burden for programmers when using references;
+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 & crp );
 void g( ®const® int * cpp );
 f( 3 );                   g( &3 );
 f( x + y );             g( &(x + y) );
+void f( ®const® int & cr );
+void g( ®const® int * cp );
+f( 3 );                   g( ®&®3 );
+f( x + y );             g( ®&®(x + y) );
 \end{cfa}
 Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
+(The ©&© is necessary for the pointer parameter to make the types match, and is a common requirement for a C programmer.)
+\CFA \emph{extends} this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed-to by the reference parameter and can be changed.
+\begin{cfa}
+void f( int & rp );
+void g( int * pp );
+f( 3 );                   g( &3 );              §\C{// compiler implicit generates temporaries}§
+f( x + y );             g( &(x + y) );  §\C{// compiler implicit generates temporaries}§
+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.}
+\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}§
 \end{cfa}
 Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
 …
 The implicit conversion allows seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call.
+While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine variables in an inconsistent way: a routine variable is both a pointer and a reference (particle and wave).
+\begin{cfa}
+void f( int p ) {...}
+void (*fp)( int ) = &f;                 §\C{// pointer initialization}§
+void (*fp)( int ) = f;                  §\C{// reference initialization}§
+(*fp)(3);                                               §\C{// pointer invocation}§
+fp(3);                                                  §\C{// reference invocation}§
+\end{cfa}
+A routine variable is best described by a ©const© reference:
+\begin{cfa}
+const void (&fp)( int ) = f;
+fp( 3 );
+fp = ...                                                §\C{// error, cannot change code}§
+&fp = ...;                                              §\C{// changing routine reference}§
+\end{cfa}
+because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{
+%\CFA attempts to handle pointers and references in a uniform, symmetric manner.
+Finally, C handles \Index{routine object}s in an inconsistent way.
+A routine object is both a pointer and a reference (\Index{particle and wave}).
+\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}§
+\end{cfa}
+because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
 Dynamic code rewriting is possible but only in special circumstances.}
+\CFA allows this additional use of references for routine variables in an attempt to give a more consistent meaning for them.
+\section{Type Operators}
+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®);
+\end{cfa}
+&
+\begin{cfa}
+y = (®int *®)x;
+i = sizeof(®int *[ 5 ]®);
+\end{cfa}
+\end{tabular}
+\end{quote2}
+\CFA allows this additional use of references for routine objects in an attempt to give a more consistent meaning for them.
+\subsection{Address-of Semantics}
+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).
+\end{itemize}
+The following example shows the first rule applied to different \Index{rvalue} contexts:
+\begin{cfa}
+int x, * px, ** ppx, *** pppx, **** ppppx;
+int & rx = x, && rrx = rx, &&& rrrx = rrx ;
+x = rrrx;               // rrrx is an lvalue with type int &&& (equivalent to x)
+px = &rrrx;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (&x)
+ppx = &&rrrx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (&rx)
+pppx = &&&rrrx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (&rrx)
+ppppx = &&&&rrrx; // starting from &&&rrrx, &&&&rrrx is an rvalue with type int **** (&rrrx)
+\end{cfa}
+The following example shows the second rule applied to different \Index{lvalue} contexts:
+\begin{cfa}
+int x, * px, ** ppx, *** pppx;
+int & rx = x, && rrx = rx, &&& rrrx = rrx ;
+rrrx = 2;               // rrrx is an lvalue with type int &&& (equivalent to x)
+&rrrx = px;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (rx)
+&&rrrx = ppx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (rrx)
+&&&rrrx = pppx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (rrrx)
+\end{cfa}
+\subsection{Conversions}
+C provides a basic implicit conversion to simplify variable usage:
+\begin{enumerate}
+\setcounter{enumi}{-1}
+\item
+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.
+\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.
+\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.
+\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 &)
+\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.
+\end{enumerate}
+\begin{comment}
+From: Richard Bilson <rcbilson@gmail.com>
+Date: Wed, 13 Jul 2016 01:58:58 +0000
+Subject: Re: pointers / references
+To: "Peter A. Buhr" <pabuhr@plg2.cs.uwaterloo.ca>
+As a general comment I would say that I found the section confusing, as you move back and forth
+between various real and imagined programming languages. If it were me I would rewrite into two
+subsections, one that specifies precisely the syntax and semantics of reference variables and
+another that provides the rationale.
+I don't see any obvious problems with the syntax or semantics so far as I understand them. It's not
+obvious that the description you're giving is complete, but I'm sure you'll find the special cases
+as you do the implementation.
+My big gripes are mostly that you're not being as precise as you need to be in your terminology, and
+that you say a few things that aren't actually true even though I generally know what you mean.
+C provides a pointer type; CFA adds a reference type. Both types contain an address, which is normally a
+location in memory.
+An address is not a location in memory; an address refers to a location in memory. Furthermore it
+seems weird to me to say that a type "contains" an address; rather, objects of that type do.
+Special addresses are used to denote certain states or access co-processor memory. By
+convention, no variable is placed at address 0, so addresses like 0, 1, 2, 3 are often used to denote no-value
+or other special states.
+This isn't standard C at all. There has to be one null pointer representation, but it doesn't have
+to be a literal zero representation and there doesn't have to be more than one such representation.
+Often dereferencing a special state causes a memory fault, so checking is necessary
+during execution.
+I don't see the connection between the two clauses here. I feel like if a bad pointer will not cause
+a memory fault then I need to do more checking, not less.
+If the programming language assigns addresses, a program's execution is sound, \ie all
+addresses are to valid memory locations.
+You haven't said what it means to "assign" an address, but if I use my intuitive understanding of
+the term I don't see how this can be true unless you're assuming automatic storage management.
+Program variables are implicit pointers to memory locations generated by the compiler and automatically
+dereferenced, as in:
+There is no reason why a variable needs to have a location in memory, and indeed in a typical
+program many variables will not. In standard terminology an object identifier refers to data in the
+execution environment, but not necessarily in memory.
+A pointer/reference is a generalization of a variable name, \ie a mutable address that can point to more
+than one memory location during its lifetime.
+I feel like you're off the reservation here. In my world there are objects of pointer type, which
+seem to be what you're describing here, but also pointer values, which can be stored in an object of
+pointer type but don't necessarily have to be. For example, how would you describe the value denoted
+by "&main" in a C program? I would call it a (function) pointer, but that doesn't satisfy your
+definition.
+not occupy storage as the literal is embedded directly into instructions.) Hence, a pointer occupies memory
+to store its current address, and the pointer's value is loaded by dereferencing, e.g.:
+As with my general objection regarding your definition of variables, there is no reason why a
+pointer variable (object of pointer type) needs to occupy memory.
+p2 = p1 + x; // compiler infers *p2 = *p1 + x;
+What language are we in now?
+pointer usage. However, in C, the following cases are ambiguous, especially with pointer arithmetic:
+p1 = p2; // p1 = p2 or *p1 = *p2
+This isn't ambiguous. it's defined to be the first option.
+p1 = p1 + 1; // p1 = p1 + 1 or *p1 = *p1 + 1
+Again, this statement is not ambiguous.
+example. Hence, a reference behaves like the variable name for the current variable it is pointing-to. The
+simplest way to understand a reference is to imagine the compiler inserting a dereference operator before
+the reference variable for each reference qualifier in a declaration, e.g.:
+It's hard for me to understand who the audience for this part is. I think a practical programmer is
+likely to be satisfied with "a reference behaves like the variable name for the current variable it
+is pointing-to," maybe with some examples. Your "simplest way" doesn't strike me as simpler than
+that. It feels like you're trying to provide a more precise definition for the semantics of
+references, but it isn't actually precise enough to be a formal specification. If you want to
+express the semantics of references using rewrite rules that's a great way to do it, but lay the
+rules out clearly, and when you're showing an example of rewriting keep your
+references/pointers/values separate (right now, you use \eg "r3" to mean a reference, a pointer,
+and a value).
+Cancellation works to arbitrary depth, and pointer and reference values are interchangeable because both
+contain addresses.
+Except they're not interchangeable, because they have different and incompatible types.
+Interestingly, C++ deals with the address duality by making the pointed-to value the default, and prevent-
+ing changes to the reference address, which eliminates half of the duality. Java deals with the address duality
+by making address assignment the default and requiring field assignment (direct or indirect via methods),
+\ie there is no builtin bit-wise or method-wise assignment, which eliminates half of the duality.
+I can follow this but I think that's mostly because I already understand what you're trying to
+say. I don't think I've ever heard the term "method-wise assignment" and I don't see you defining
+it. Furthermore Java does have value assignment of basic (non-class) types, so your summary here
+feels incomplete. (If it were me I'd drop this paragraph rather than try to save it.)
+Hence, for type & const, there is no pointer assignment, so &rc = &x is disallowed, and the address value
+cannot be 0 unless an arbitrary pointer is assigned to the reference.
+Given the pains you've taken to motivate every little bit of the semantics up until now, this last
+clause ("the address value cannot be 0") comes out of the blue. It seems like you could have
+perfectly reasonable semantics that allowed the initialization of null references.
+In effect, the compiler is managing the
+addresses for type & const not the programmer, and by a programming discipline of only using references
+with references, address errors can be prevented.
+Again, is this assuming automatic storage management?
+rary binding. For reference initialization (like pointer), the initializing value must be an address (lvalue) not
+a value (rvalue).
+This sentence appears to suggest that an address and an lvalue are the same thing.
+int * p = &x; // both &x and x are possible interpretations
+Are you saying that we should be considering "x" as a possible interpretation of the initializer
+"&x"? It seems to me that this expression has only one legitimate interpretation in context.
+int & r = x; // x unlikely interpretation, because of auto-dereferencing
+You mean, we can initialize a reference using an integer value? Surely we would need some sort of
+cast to induce that interpretation, no?
+Hence, the compiler implicitly inserts a reference operator, &, before the initialization expression.
+But then the expression would have pointer type, which wouldn't be compatible with the type of r.
+Similarly,
+when a reference is used for a parameter/return type, the call-site argument does not require a reference
+operator.
+Furthermore, it would not be correct to use a reference operator.
+The implicit conversion allows
+seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call.
+While C' attempts to handle pointers and references in a uniform, symmetric manner, C handles routine
+variables in an inconsistent way: a routine variable is both a pointer and a reference (particle and wave).
+After all this talk of how expressions can have both pointer and value interpretations, you're
+disparaging C because it has expressions that have both pointer and value interpretations?
+On Sat, Jul 9, 2016 at 4:18 PM Peter A. Buhr <pabuhr@plg.uwaterloo.ca> wrote:
+> Aaron discovered a few places where "&"s are missing and where there are too many "&", which are
+> corrected in the attached updated. None of the text has changed, if you have started reading
+> already.
+\end{comment}
 \section{Routine Definition}
 \CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax.
+\CFA also supports a new syntax for routine definition, as well as \Celeven and K\&R routine syntax.
 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
 \begin{cfa}
 …
 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}
 …
 \begin{cfa}
 typedef int foo;
 int f( int (* foo) );                   §\C{// foo is redefined as a parameter name}§
+int f( int (* foo) );                           §\C{// foo is redefined as a parameter name}§
 \end{cfa}
 The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
 …
 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.
 …
         int z;
         ... x = 0; ... y = z; ...
         ®return;® §\C{// implicitly return x, y}§
+        ®return;®                                                       §\C{// implicitly return x, y}§
+}
 \end{cfa}
 …
 [ int x, int y ] f() {
         ...
 } §\C{// implicitly return x, y}§
+}                                                                               §\C{// implicitly return x, y}§
 \end{cfa}
 In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
+Named return values may be used in conjunction with named parameter values;
+specifically, a return and parameter can have the same name.
+\begin{cfa}
+[ int x, int y ] f( int, x, int 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 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.
+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).
 …
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
 [ int ] f(int), g;
+[ int ] f( int ), g;
 \end{cfa}
+&
 \begin{cfa}
 int f(int), g(int);
+int f( int ), g( int );
 \end{cfa}
 \end{tabular}
 …
 Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:
 \begin{cfa}
 extern [ int ] f (int);
 static [ int ] g (int);
+extern [ int ] f ( int );
+static [ int ] g ( int );
 \end{cfa}
 …
 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}
 …
 \section{Named and Default Arguments}
 Named and default arguments~\cite{Hardgrave76}\footnote{
+Named\index{named arguments}\index{arguments!named} and default\index{default arguments}\index{arguments!default} arguments~\cite{Hardgrave76}\footnote{
 Francez~\cite{Francez77} proposed a further extension to the named-parameter passing style, which specifies what type of communication (by value, by reference, by name) the argument is passed to the routine.}
 are two mechanisms to simplify routine call.
 …
 Given the \CFA restrictions above, both named and default arguments are backwards compatible.
 \Index*[C++]{\CC} only supports default arguments;
+\Index*[C++]{\CC{}} only supports default arguments;
 \Index*{Ada} supports both named and default arguments.
+\section{Type/Routine Nesting}
+\section{Unnamed Structure Fields}
+C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg:
+\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}§
+};
+\end{cfa}
+This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed.
+As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size.
+A list of unnamed fields is also supported, \eg:
+\begin{cfa}
+struct {
+        int , , ;                               §\C{// 3 unnamed fields}§
+}
+\end{cfa}
+\section{Nesting}
 Nesting of types and routines is useful for controlling name visibility (\newterm{name hiding}).
 …
 \subsection{Type Nesting}
 \CFA allows \Index{type nesting}, and type qualification of the nested typres (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
+\CFA allows \Index{type nesting}, and type qualification of the nested types (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
 \begin{figure}
 \centering
 …
+}
 int main() {
         * [int](int) fp = foo();        §\C{// int (*fp)(int)}§
     sout | fp( 3 ) | endl;
+        * [int]( int ) fp = foo();      §\C{// int (*fp)( int )}§
+        sout | fp( 3 ) | endl;
+}
 \end{cfa}
 because
 Currently, there are no \Index{lambda} expressions, i.e., unnamed routines because routine names are very important to properly select the correct routine.
 \section{Lexical List}
+Currently, there are no \Index{lambda} expressions, \ie unnamed routines because routine names are very important to properly select the correct routine.
+\section{Tuples}
 In C and \CFA, lists of elements appear in several contexts, such as the parameter list for a routine call.
 …
 [ v+w, x*y, 3.14159, f() ]
 \end{cfa}
 Tuples are permitted to contain sub-tuples (i.e., nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.
+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).
 …
 tuple does not have structure like a record; a tuple is simply converted into a list of components.
 \begin{rationale}
 The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; i.e., a statement such as ©g( f() )© is not supported.
+The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; \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}
 …
 This requirement is the same as for comma expressions in argument lists.
 Type qualifiers, i.e., const and volatile, may modify a tuple type.
 The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, \eg:
+Type qualifiers, \ie const and volatile, may modify a tuple type.
+The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], \ie the qualifier is distributed across all of the types in the tuple, \eg:
 \begin{cfa}
 const volatile [ int, float, const int ] x;
 …
 ©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:
+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:
 \begin{cfa}
 [ a, b, c, d ] = [ 1, [ 2, 3 ], 4 ];
 …
 \end{cfa}
 \index{lvalue}
 The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, i.e., any data object that can appear on the left-hand side of a conventional assignment statement.
+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.
 Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
 …
 \index{lvalue}
 The left-hand side is a tuple of \emph{lvalues}, and the right-hand side is a tuple of \emph{expr}s.
 Each \emph{expr} appearing on the righthand side of a multiple assignment statement is assigned to the corresponding \emph{lvalues} on the left-hand side of the statement using parallel semantics for each assignment.
+Each \emph{expr} appearing on the right-hand side of a multiple assignment statement is assigned to the corresponding \emph{lvalues} on the left-hand side of the statement using parallel semantics for each assignment.
 An example of multiple assignment is:
 \begin{cfa}
 …
 [ x1, y1 ] = z = 0;
 \end{cfa}
+As in C, the rightmost assignment is performed first, i.e., assignment parses right to left.
+\section{Unnamed Structure Fields}
+C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg:
+\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}§
+};
+\end{cfa}
+This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed.
+As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size.
+A list of unnamed fields is also supported, \eg:
+\begin{cfa}
+struct {
+        int , , ;                               §\C{// 3 unnamed fields}§
+}
+\end{cfa}
+As in C, the rightmost assignment is performed first, \ie assignment parses right to left.
 …
 \section{Labelled Continue / Break}
+\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.
 Unfortunately, this restriction forces programmers to use ©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 ©continue©\index{continue@©continue©}\index{continue@©continue©!labelled}\index{labelled!continue@©continue©} and ©break©\index{break@©break©}\index{break@©break©!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85,Java}.
+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.
+The following example shows the labelled ©continue© specifying which control structure is the target for the next loop iteration:
+\begin{quote2}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{cfa}
+®L1:® do {
+        ®L2:® while ( ... ) {
+                ®L3:® for ( ... ) {
+                        ... continue ®L1®; ...  // continue do
+                        ... continue ®L2®; ...  // continue while
+                        ... continue ®L3®; ...  // continue for
+                } // for
+        } // while
+} while ( ... );
+\end{cfa}
+&
+\begin{cfa}
+do {
+        while ( ... ) {
+                for ( ... ) {
+                        ... goto L1; ...
+                        ... goto L2; ...
+                        ... goto L3; ...
+                L3: ; }
+        L2: ; }
+L1: ; } while ( ... );
+\end{cfa}
+\end{tabular}
+\end{quote2}
+The innermost loop has three restart points, which cause the next loop iteration to begin.
+The following example shows the labelled ©break© specifying which control structure is the target for exit:
+\begin{quote2}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{cfa}
+®L1:® {
+\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.
+\begin{figure}
+\begin{tabular}{@{\hspace{\parindentlnth}}l@{\hspace{1.5em}}l@{}}
+\multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{\CFA}}      & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{cfa}
+®LC:® {
         ... §declarations§ ...
         ®L2:® switch ( ... ) {
+        ®LS:® switch ( ... ) {
           case 3:
+            ®L3:® if ( ... ) {
+                        ®L4:® for ( ... ) {
+                                ... break ®L1®; ...     // exit compound statement
+                                ... break ®L2®; ...     // exit switch
+                                ... break ®L3®; ...     // exit if
+                                ... break ®L4®; ...     // exit 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 ®L3®; ...             // exit if
+                        ... break ®LIF®; ...                                     // terminate if
                 } // if
         } // switch
 …
         switch ( ... ) {
           case 3:
             if ( ... ) {
+                if ( ... ) {
                         for ( ... ) {
+                                ... goto L1; ...
+                                ... goto L2; ...
+                                ... goto L3; ...
+                                ... goto L4; ...
+                        } L4: ;
+                                while ( ... ) {
+                                        ... goto ®LC®; ...
+                                        ... goto ®LS®; ...
+                                        ... goto ®LIF®; ...
+                                        ... goto ®LFC®; ...
+                                        ... goto ®LFB®; ...
+                                        ... goto ®LWC®; ...
+                                        ... goto ®LWB®; ...
+                                  ®LWC®: ; } ®LWB:® ;
+                          ®LFC:® ; } ®LFB:® ;
                 } else {
                         ... goto L3; ...
                 } L3: ;
         } L2: ;
 } L1: ;
+                        ... goto ®LIF®; ...
+                } ®L3:® ;
+        } ®LS:® ;
+} ®LC:® ;
 \end{cfa}
 \end{tabular}
+\end{quote2}
+The innermost loop has four exit points, which cause termination of one or more of the four \Index{nested control structure}s.
+Both ©continue© and ©break© with target labels are simply a ©goto©\index{goto@©goto©!restricted} restricted in the following ways:
+\caption{Multi-level Resume/Termination}
+\label{f:MultiLevelResumeTermination}
+\end{figure}
+\begin{comment}
+int main() {
+  LC: {
+          LS: switch ( 1 ) {
+                  case 3:
+                  LIF: if ( 1 ) {
+                          LF: for ( ;; ) {
+                                  LW: while ( 1 ) {
+                                                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
+                        } // if
+                } // switch
+        } // compound
+        {
+                switch ( 1 ) {
+                  case 3:
+                        if ( 1 ) {
+                                for ( ;; ) {
+                                        while ( 1 ) {
+                                                goto LCx;
+                                                goto LSx;
+                                                goto LIF;
+                                                goto LFC;
+                                                goto LFB;
+                                                goto LWC;
+                                                goto LWB;
+                                          LWC: ; } LWB: ;
+                                  LFC: ; } LFB: ;
+                        } else {
+                                goto LIF;
+                        } L3: ;
+                } LSx: ;
+        } LCx: ;
+}
+// Local Variables: //
+// tab-width: 4 //
+// End: //
+\end{comment}
+Both labelled ©continue© and ©break© are a ©goto©\index{goto@\lstinline $goto$!restricted} restricted in the following ways:
 \begin{itemize}
 \item
 They cannot be used to create a loop.
 This means that only the looping construct can be used to create a loop.
+This restriction is important since all situations that can result in repeated execution of statements in a program are clearly delineated.
+\item
 Since they always transfer out of containing control structures, they cannot be used to branch into a control structure.
+They cannot create a loop, which means only the looping constructs cause looping.
+This restriction means all situations resulting in repeated execution are clearly delineated.
+\item
+They cannot branch into a control structure.
+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.
 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©, i.e., 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.
 …
 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, i.e., there are multiple entry points into its statement body.
+The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
 \end{enumerate}
 …
 the number of ©switch© statements is small,
 \item
 most ©switch© statements are well formed (i.e., no \Index*{Duff's device}),
+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
 Eliminating default fall-through has the greatest potential for affecting existing code.
 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, i.e., a list of ©case© clauses executing common code, \eg:
+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: ...
 …
         ®int j = 0;®                            §\C{// disallowed}§
   case 1:
+    {
+        {
                 ®int k = 0;®                    §\C{// allowed at different nesting levels}§
                 ...
 …
 \index{input/output library}
+The goal for the \CFA I/O is to make I/O as simple as possible in the common cases, while fully supporting polymorphism and user defined types in a consistent way.
+The goal of \CFA I/O is to simplify the common cases\index{I/O!common case}, while fully supporting polymorphism and user defined types in a consistent way.
+The \CFA header file for the I/O library is \Indexc{fstream}.
 The common case is printing out a sequence of variables separated by whitespace.
 \begin{quote2}
 …
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
 \begin{cfa}
 int x = 0, y = 1, z = 2;
+int x = 1, y = 2, z = 3;
 sout | x ®|® y ®|® z | endl;
 \end{cfa}
 …
 cout << x ®<< " "® << y ®<< " "® << z << endl;
+\end{cfa}
+\\
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+2 3
+\end{cfa}
+&
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+2 3
 \end{cfa}
 \end{tabular}
 \end{quote2}
 The \CFA form has half as many characters as the \CC form, and is similar to \Index*{Python} I/O with respect to implicit separators.
+The logical-or operator is used because it is the lowest-priority overloadable operator, other than assignment.
+A tuple prints all the tuple's values, each separated by ©", "©.
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+[int, int] t1 = [1, 2], t2 = [3, 4];
+sout | t1 | t2 | endl;                                  §\C{// print tuples}§
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,belowskip=0pt]
+, 2, 3, 4
+\end{cfa}
+\CFA uses the logical-or operator for I/O because it is the lowest-priority overloadable operator, other than assignment.
 Therefore, fewer output expressions require parenthesis.
 \begin{quote2}
 …
+&
 \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}
+\\
+&
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+3 12 0 3 1 2
 \end{cfa}
 \end{tabular}
 …
 Finally, the logical-or operator has a link with the Shell pipe-operator for moving data, where data flows in the correct direction for input but the opposite direction for output.
+The implicit separator\index{I/O separator} character (space/blank) is a separator not a terminator.
+The implicit separator\index{I/O!separator} character (space/blank) is a separator not a terminator.
 The rules for implicitly adding the separator are:
 \begin{enumerate}
 …
 2 3
 \end{cfa}
 \item
 A separator does not appear before or after a character literal or variable.
 …
 \end{cfa}
+\item
+A separator does not appear before or after a null (empty) C string
+\item
+A separator does not appear before or after a null (empty) C string.
 \begin{cfa}
 sout | 1 | "" | 2 | "" | 3 | endl;
 …
 \end{cfa}
 which is a local mechanism to disable insertion of the separator character.
+\item
+A separator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{=$£¥¡¿«@
+\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]@([{=$£¥¡¿«@
 %$
 \begin{cfa}[mathescape=off]
 …
 \end{cfa}
 %$
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 x (1 x [2 x {3 x =4 x $5 x £6 x ¥7 x ¡8 x ¿9 x «10
+\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
 \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: ©,.;!?)]}%¢»©
+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;
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
 , x 2. x 3; x 4! x 5? x 6% x 7§\textcent§ x 8» x 9) x 10] x 11} x
+\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
 \end{cfa}}%
+\item
+A seperator does not appear before or after a C string begining/ending with the \Index{ASCII} quote or whitespace characters: \lstinline[showspaces=true]@`'": \t\v\f\r\n@
+where \lstinline[basicstyle=\tt]@»@ is a closing citation mark.
+\item
+A seperator does not appear before or after a C string begining/ending with the \Index*{ASCII} quote or whitespace characters: \lstinline[basicstyle=\tt,showspaces=true]@`'": \t\v\f\r\n@
 \begin{cfa}[belowskip=0pt]
 sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx" | endl;
 \end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
+x`1`x'2'x"3"x:4:x 5 x   6       x
+\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
+\end{cfa}
+\item
+If a space is desired before or after one of the special string start/end characters, simply insert a space.
+\begin{cfa}[belowskip=0pt]
+sout | "x (§\color{red}\texttt{\textvisiblespace}§" | 1 | "§\color{red}\texttt{\textvisiblespace}§) x" | 2 | "§\color{red}\texttt{\textvisiblespace}§, x" | 3 | "§\color{red}\texttt{\textvisiblespace}§:x:§\color{red}\texttt{\textvisiblespace}§" | 4 | endl;
+\end{cfa}
+\begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
+x (® ®1® ®) x 2® ®, x 3® ®:x:® ®4
 \end{cfa}
 \end{enumerate}
+The following \CC-style \Index{manipulator}s allow control over implicit seperation.
+Manipulators \Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} \emph{locally} toggle printing the separator, i.e., the seperator is adjusted only with respect to the next printed item.
+The following routines and \CC-style \Index{manipulator}s control implicit seperation.
+\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).
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+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 ®", $"®
+\end{cfa}
+%$
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+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
+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 of line}§
 …
 3
 \end{cfa}
+Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} \emph{globally} toggle printing the separator, i.e., the seperator is adjusted with respect to all subsequent printed items, unless locally adjusted.
+\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.
 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
 sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// globally turn off implicit separation}§
 …
 2 3
 \end{cfa}
+Printing a tuple outputs all the tuple's values separated by ©", "©:
+\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]
+sout | [2, 3] | [4, 5] | endl;                          §\C{// print tuple}§
+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 ®" "®
+\end{cfa}
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+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
+The tuple separator can also be 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}§
 \end{cfa}
 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+, 3, 4, 5
+\end{cfa}
+The tuple separator can also be turned on and off:
+\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
+sout | sepOn | [2, 3] | sepOff | [4, 5] | endl; §\C{// locally turn on/off implicit separation}§
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
+, 2, 34, 5
+, 1, 23, 4
 \end{cfa}
 Notice a tuple seperator starts the line because the next item is a tuple.
+Finally, the stream routines \Indexc{sepGet}\index{manipulator!sepGet@©sepGet©} and \Indexc{sepSet}\index{manipulator!sepSet@©sepSet©} get and set the basic separator-string.
+\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
+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 ", $"
+\end{cfa}
+%$
+\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
+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}
+and the stream routines \Indexc{sepGetTuple}\index{manipulator!sepGetTuple@©sepGetTuple©} and \Indexc{sepSetTuple}\index{manipulator!sepSetTuple@©sepSetTuple©} get and set the tuple separator-string.
+\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
+sepSetTuple( sout, " " );                                       §\C{// set tuple separator from ", " to " "}§
+sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl;
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
+3 4 5 " "
+\end{cfa}
+\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
+sepSetTuple( sout, ", " );                                      §\C{// reset tuple separator to ", "}§
+sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl;
+\end{cfa}
+\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
+, 3, 4, 5 ", "
+\end{cfa}
+\end{enumerate}
 \begin{comment}
 …
 int main( void ) {
+        int x = 0, y = 1, z = 2;
+        sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl | endl;
+        int x = 1, y = 2, z = 3;
+        sout | x | y | z | endl;
+        [int, int] t1 = [1, 2], t2 = [3, 4];
+        sout | t1 | t2 | endl;                                          // print tuple
+        sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
         sout | 1 | 2 | 3 | endl;
         sout | '1' | '2' | '3' | endl;
 …
                 | 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 | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
+        sout | 1 | sepOff | 2 | 3 | endl;                       // locally turn off implicit separator
+        sout | sepDisable | 1 | 2 | 3 | endl;           // globally turn off implicit separation
+        sout | 1 | sepOn | 2 | 3 | endl;                        // locally turn on implicit separator
+        sout | sepEnable | 1 | 2 | 3 | endl;            // globally turn on implicit separation
+        sout | [2, 3] | [4, 5] | endl;                          // print tuple
+        sout | sepOn | [2, 3] | sepOff | [4, 5] | endl; // locally turn on/off implicit separation
+        sout | "x ( " | 1 | " ) x" | 2 | " , x" | 3 | " :x: " | 4 | endl;
         sepSet( sout, ", $" );                                          // set separator from " " to ", $"
 …
         sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
+        sout | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
+        sout | 1 | sepOff | 2 | 3 | endl;                       // locally turn off implicit separator
+        sout | sepDisable | 1 | 2 | 3 | endl;           // globally turn off implicit separation
+        sout | 1 | sepOn | 2 | 3 | endl;                        // locally turn on implicit separator
+        sout | sepEnable | 1 | 2 | 3 | endl;            // globally turn on implicit separation
         sepSetTuple( sout, " " );                                       // set tuple separator from ", " to " "
         sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl;
+        sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"" | endl;
         sepSetTuple( sout, ", " );                                      // reset tuple separator to ", "
+        sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl;
+        sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"" | endl;
+        sout | t1 | t2 | endl;                                          // print tuple
+        sout | sepOn | t1 | sepOff | t2 | endl;         // locally turn on/off implicit separation
+}
 // Local Variables: //
 // tab-width: 4 //
+// fill-column: 100 //
 // End: //
 \end{comment}
 …
 \subsection{Constructors and Destructors}
+\section{Constructors and Destructors}
 \CFA supports C initialization of structures, but it also adds constructors for more advanced initialization.
 Additionally, \CFA adds destructors that are called when a variable is de-allocated (variable goes out of scope or object is deleted).
+Additionally, \CFA adds destructors that are called when a variable is deallocated (variable goes out of scope or object is deleted).
 These functions take a reference to the structure as a parameter (see References for more information).
 …
 \caption{Constructors and Destructors}
 \end{figure}
-\begin{comment}
-\section{References}
-By introducing references in parameter types, users are given an easy way to pass a value by reference, without the need for NULL pointer checks.
-In structures, a reference can replace a pointer to an object that should always have a valid value.
-When a structure contains a reference, all of its constructors must initialize the reference and all instances of this structure must initialize it upon definition.
-The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.
-Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
-When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
-The ©&© is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.
-\end{comment}
 …
+\begin{comment}
 \section{Generics}
 …
 Generics allow programmers to use type variables in place of concrete types so that the code can be reused with multiple types.
 The type parameters can be restricted to satisfy a set of constraints.
 This enables \CFA to build fully compiled generic functions and types, unlike other languages like \Index*[C++]{\CC} where templates are expanded or must be explicitly instantiated.
+This enables \CFA to build fully compiled generic functions and types, unlike other languages like \Index*[C++]{\CC{}} where templates are expanded or must be explicitly instantiated.
 \subsection{Generic Functions}
 Generic functions in \CFA are similar to template functions in \Index*[C++]{\CC}, and will sometimes be expanded into specialized versions, just like in \CC.
+Generic functions in \CFA are similar to template functions in \Index*[C++]{\CC{}}, and will sometimes be expanded into specialized versions, just like in \CC.
 The difference, however, is that generic functions in \CFA can also be separately compiled, using function pointers for callers to pass in all needed functionality for the given type.
 This means that compiled libraries can contain generic functions that can be used by programs linked with them (statically or dynamically).
 …
 generic (type T | bool ?<?(T, T) )
 T min(T a, T b) {
+T min( T a, T b ) {
         return a < b ? a : b;
+}
 …
 generic (type T | Orderable(T))
 T min(T a, T b) {
+T min( T a, T b ) {
         return a < b ? a : b;
+}
 …
 Generic types are defined using the same mechanisms as those described above for generic functions.
 This feature allows users to create types that have one or more fields that use generic parameters as types, similar to a template classes in \Index*[C++]{\CC}.
+This feature allows users to create types that have one or more fields that use generic parameters as types, similar to a template classes in \Index*[C++]{\CC{}}.
 For example, to make a generic linked list, a placeholder is created for the type of the elements, so that the specific type of the elements in the list need not be specified when defining the list.
 In C, something like this would have to be done using void pointers and unsafe casting.
 …
 Throwing an exception terminates execution of the current block, invokes the destructors of variables that are local to the block, and propagates the exception to the parent block.
 The exception is immediately re-thrown from the parent block unless it is caught as described below.
 \CFA uses keywords similar to \Index*[C++]{\CC} for exception handling.
+\CFA uses keywords similar to \Index*[C++]{\CC{}} for exception handling.
 An exception is thrown using a throw statement, which accepts one argument.
 …
+        }
 \end{cfa}
+\end{comment}
 …
         Complex *p3 = new(0.5, 1.0); // allocate + 2 param constructor
+}
 \end{cfa}
 …
+\begin{comment}
 \subsection{Unsafe C Constructs}
 …
 The exact set of unsafe C constructs that will be disallowed in \CFA has not yet been decided, but is sure to include pointer arithmetic, pointer casting, etc.
 Once the full set is decided, the rules will be listed here.
+\end{comment}
 \section{Concurrency}
-Today's processors for nearly all use cases, ranging from embedded systems to large cloud computing servers, are composed of multiple cores, often heterogeneous.
-As machines grow in complexity, it becomes more difficult for a program to make the most use of the hardware available.
-\CFA includes built-in concurrency features to enable high performance and improve programmer productivity on these multi-/many-core machines.
 Concurrency support in \CFA is implemented on top of a highly efficient runtime system of light-weight, M:N, user level threads.
 …
 This enables a very familiar interface to all programmers, even those with no parallel programming experience.
 It also allows the compiler to do static type checking of all communication, a very important safety feature.
+This controlled communication with type safety has some similarities with channels in \Index*{Go}, and can actually implement
+channels exactly, as well as create additional communication patterns that channels cannot.
+This controlled communication with type safety has some similarities with channels in \Index*{Go}, and can actually implement channels exactly, as well as create additional communication patterns that channels cannot.
 Mutex objects, monitors, are used to contain mutual exclusion within an object and synchronization across concurrent threads.
+Three new keywords are added to support these features:
+monitor creates a structure with implicit locking when accessing fields
+mutex implies use of a monitor requiring the implicit locking
+task creates a type with implicit locking, separate stack, and a thread
+\begin{figure}
+\begin{cfa}
+#include <fstream>
+#include <coroutine>
+coroutine Fibonacci {
+        int fn;                                                         §\C{// used for communication}§
+};
+void ?{}( Fibonacci * this ) {
+        this->fn = 0;
+}
+void main( Fibonacci * this ) {
+        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}§
+        fn2 = fn1;
+        fn1 = this->fn;
+        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}§
+        } // for
+}
+int next( Fibonacci * this ) {
+        resume( this );                                         §\C{// transfer to last suspend}§
+        return this->fn;
+}
+int main() {
+        Fibonacci f1, f2;
+        for ( int i = 1; i <= 10; i += 1 ) {
+                sout | next( &f1 ) | ' ' | next( &f2 ) | endl;
+        } // for
+}
+\end{cfa}
+\caption{Fibonacci Coroutine}
+\label{f:FibonacciCoroutine}
+\end{figure}
+\subsection{Coroutine}
+\Index{Coroutines} are the precursor to tasks.
+\VRef[Figure]{f:FibonacciCoroutine} shows a coroutine that computes the \Index*{Fibonacci} numbers.
 …
 \end{cfa}
+\begin{figure}
+\begin{cfa}
+#include <fstream>
+#include <kernel>
+#include <monitor>
+#include <thread>
+monitor global_t {
+        int value;
+};
+void ?{}(global_t * this) {
+        this->value = 0;
+}
+static global_t global;
+void increment3( global_t * mutex this ) {
+        this->value += 1;
+}
+void increment2( global_t * mutex this ) {
+        increment3( this );
+}
+void increment( global_t * mutex this ) {
+        increment2( this );
+}
+thread MyThread {};
+void main( MyThread* this ) {
+        for(int i = 0; i < 1_000_000; i++) {
+                increment( &global );
+        }
+}
+int main(int argc, char* argv[]) {
+        processor p;
+        {
+                MyThread f[4];
+        }
+        sout | global.value | endl;
+}
+\end{cfa}
+\caption{Atomic-Counter Monitor}
+\caption{f:AtomicCounterMonitor}
+\end{figure}
+\begin{comment}
 Since a monitor structure includes an implicit locking mechanism, it does not make sense to copy a monitor;
 it is always passed by reference.
 …
+}
 \end{cfa}
+\end{comment}
 …
 A task provides mutual exclusion like a monitor, and also has its own execution state and a thread of control.
 Similar to a monitor, a task is defined like a structure:
+\begin{figure}
+\begin{cfa}
+#include <fstream>
+#include <kernel>
+#include <stdlib>
+#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 ) {
+                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 ) {
+                sout | "Second : Suspend No." | i + 1 | endl;
+                yield();
+        }
+}
+int main( void ) {
+        signal_once lock;
+        sout | "User main begin" | endl;
+        {
+                processor p;
+                {
+                        First  f = { &lock };
+                        Second s = { &lock };
+                }
+        }
+        sout | "User main end" | endl;
+}
+\end{cfa}
+\caption{Simple Tasks}
+\label{f:SimpleTasks}
+\end{figure}
+\begin{comment}
 \begin{cfa}
 type Adder = task {
 …
 A task may define a constructor, which will be called upon allocation and run on the caller.s thread.
 A destructor may also be defined, which is called at de-allocation (when a dynamic object is deleted or when a local object goes out of scope).
+A destructor may also be defined, which is called at deallocation (when a dynamic object is deleted or when a local object goes out of scope).
 After a task is allocated and initialized, its thread is spawned implicitly and begins executing in its function call method.
 All tasks must define this function call method, with a void return value and no additional parameters, or the compiler will report an error.
 …
 \end{cfa}
 \subsection{Cooperative Scheduling}
 …
+}
 \end{cfa}
+\end{comment}
+\begin{comment}
 \section{Modules and Packages }
-\begin{comment}
 High-level encapsulation is useful for organizing code into reusable units, and accelerating compilation speed.
 \CFA provides a convenient mechanism for creating, building and sharing groups of functionality that enhances productivity and improves compile time.
 …
 \subsection{No Declarations, No Header Files}
 In C and \Index*[C++]{\CC}, it is necessary to declare or define every global variable, global function, and type before it is used in each file.
+In C and \Index*[C++]{\CC{}}, it is necessary to declare or define every global variable, global function, and type before it is used in each file.
 Header files and a preprocessor are normally used to avoid repeating code.
 Thus, many variables, functions, and types are described twice, which exposes an opportunity for errors and causes additional maintenance work.
 …
 In developing \CFA, many other languages were consulted for ideas, constructs, and syntax.
 Therefore, it is important to show how these languages each compare with Do.
+In this section, \CFA is compared with what the writers of this document consider to be the closest competitors of Do: \Index*[C++]{\CC}, \Index*{Go}, \Index*{Rust}, and \Index*{D}.
+In this section, \CFA is compared with what the writers of this document consider to be the closest competitors of Do: \Index*[C++]{\CC{}}, \Index*{Go}, \Index*{Rust}, and \Index*{D}.
+\begin{comment}
 \subsection[Comparing Key Features of CFA]{Comparing Key Features of \CFA}
 …
-\begin{comment}
 \subsubsection{Modules / Packages}
 …
+}
 \end{cfa}
-\end{comment}
 …
 \subsection{Summary of Language Comparison}
+\subsubsection[C++]{\CC}
+\Index*[C++]{\CC} is a general-purpose programming language.
+\end{comment}
+\subsection[C++]{\CC}
+\Index*[C++]{\CC{}} is a general-purpose programming language.
 It has imperative, object-oriented and generic programming features, while also providing facilities for low-level memory manipulation. (Wikipedia)
 …
 \subsubsection{Go}
+\subsection{Go}
 \Index*{Go}, also commonly referred to as golang, is a programming language developed at Google in 2007 [.].
 …
 \subsubsection{Rust}
+\subsection{Rust}
 \Index*{Rust} is a general-purpose, multi-paradigm, compiled programming language developed by Mozilla Research.
 …
 \subsubsection{D}
+\subsection{D}
 The \Index*{D} programming language is an object-oriented, imperative, multi-paradigm system programming
 …
+\section{Syntactic Anomalies}
+There are several ambiguous cases with operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©~\R{/}~©?*?© or ©*?©~\R{/}~©*?©.
+Since it is common practise to put a unary operator juxtaposed to an identifier, \eg ©*i©, users will be annoyed if they cannot do this with respect to operator identifiers.
+Even with this special hack, there are 5 general cases that cannot be handled.
+The first case is for the function-call identifier ©?()©:
+\begin{cfa}
+int *§\textvisiblespace§?()();  // declaration: space required after '*'
+*§\textvisiblespace§?()();              // expression: space required after '*'
+\end{cfa}
+Without the space, the string ©*?()© is ambiguous without N character look ahead;
+it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list.
+The 4 remaining cases occur in expressions:
+\begin{cfa}
+i++§\textvisiblespace§?i:0;             // space required before '?'
+i--§\textvisiblespace§?i:0;             // space required before '?'
+i§\textvisiblespace§?++i:0;             // space required after '?'
+i§\textvisiblespace§?--i:0;             // space required after '?'
+\end{cfa}
+In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©;
+it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
+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.
+\section{Incompatible}
+The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
+\begin{enumerate}
+\item
+\begin{description}
+\item[Change:] add new keywords \\
+New keywords are added to \CFA (see~\VRef{s:NewKeywords}).
+\item[Rationale:] keywords added to implement new semantics of \CFA.
+\item[Effect on original feature:] change to semantics of well-defined feature. \\
+Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
+\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}):
+\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
+\end{description}
+\item
+\begin{description}
+\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.
+\begin{cfa}
+sout | 'x' | " " | (int)'x' | endl;
+x 120
+\end{cfa}
+Having to cast ©'x'© to ©char© is non-intuitive.
+\item[Effect on original feature:] change to semantics of well-defined feature that depend on:
+\begin{cfa}
+sizeof( 'x' ) == sizeof( int )
+\end{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)©.
+\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[Rationale:] This change is a safety issue:
+\begin{cfa}
+char * p = "abc";
+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[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
+\end{description}
+\item
+\begin{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}§
+\end{cfa}
+is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
+This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example,
+\begin{cfa}
+struct X { int i; struct X *next; };
+static struct X a;                              §\C{// forward definition}§
+static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
+static struct X a = { 1, &b };  §\C{// definition}§
+\end{cfa}
+\item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] the initializer for one of a set of mutually-referential file-local static objects must invoke a routine call to achieve the initialization.
+\item[How widely used:] seldom
+\end{description}
+\item
+\begin{description}
+\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)}§
+        };
+        ß.ß®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}§
+\end{cfa}
+In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, i.e., the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
+\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
+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[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
+\end{description}
+\item
+\begin{description}
+\item[Change:] In C++, the name of a nested class is local to its enclosing class.
+\item[Rationale:] C++ classes have member functions which require that classes establish scopes.
+\item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
+\begin{cfa}
+struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
+struct X {
+struct Y { /* ... */ } y;
+};
+\end{cfa}
+All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct.
+Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
+\item[How widely used:] Seldom.
+\end{description}
+\item
+\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[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[How widely used:] seldom.
+\end{description}
+\end{enumerate}
+\section{Syntax Ambiguities}
+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.
+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}§
+\end{cfa}
+By default, the first interpretation is selected, which does not yield a meaningful parse.
+Therefore, \CFA does a lexical look-ahead for the second case, and backtracks to return the leading unary operator and reparses the trailing operator identifier.
+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.
+The ambiguity occurs when the deference operator has no parameters:
+\begin{cfa}
+*?()§\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.
+The remaining cases are with the increment/decrement operators and conditional expression, \eg:
+\begin{cfa}
+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;
+\end{cfa}
 …
 \begin{quote2}
 \begin{tabular}{lll}
+\begin{tabular}{llll}
 \begin{tabular}{@{}l@{}}
 ©_AT©                   \\
 …
 ©coroutine©             \\
 ©disable©               \\
-©dtype©                 \\
-©enable©                \\
 \end{tabular}
+&
 \begin{tabular}{@{}l@{}}
+©dtype©                 \\
+©enable©                \\
 ©fallthrough©   \\
 ©fallthru©              \\
 ©finally©               \\
 ©forall©                \\
+\end{tabular}
+&
+\begin{tabular}{@{}l@{}}
 ©ftype©                 \\
 ©lvalue©                \\
 ©monitor©               \\
 ©mutex©                 \\
+©one_t©                 \\
+©otype©                 \\
 \end{tabular}
+&
 \begin{tabular}{@{}l@{}}
-©one_t©                 \\
-©otype©                 \\
 ©throw©                 \\
 ©throwResume©   \\
 …
+\section{Incompatible}
+The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{C++14}.
+\begin{enumerate}
+\item
+\begin{description}
+\item[Change:] add new keywords \\
+New keywords are added to \CFA (see~\VRef{s:CFAKeywords}).
+\item[Rationale:] keywords added to implement new semantics of \CFA.
+\item[Effect on original feature:] change to semantics of well-defined feature. \\
+Any \Celeven programs using these keywords as identifiers are invalid \CFA programs.
+\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}).
+\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
+\end{description}
+\item
+\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.
+\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 );}§
+\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}§
+{
+        ...
+}
+\end{cfa}
+\item[Rationale:] dropped from \Celeven standard.\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}}
+\item[Effect on original feature:] original feature is deprecated. \\
+Any old C programs using these K\&R declarations are invalid \CFA programs.
+\item[Difficulty of converting:] trivial to convert to \CFA.
+\item[How widely used:] existing usages are rare.
+\end{description}
+\item
+\begin{description}
+\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.
+\begin{cfa}
+sout | 'x' | " " | (int)'x' | endl;
+x 120
+\end{cfa}
+Having to cast ©'x'© to ©char© is non-intuitive.
+\item[Effect on original feature:] change to semantics of well-defined feature that depend on:
+\begin{cfa}
+sizeof( 'x' ) == sizeof( int )
+\end{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)©.
+\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[Rationale:] This change is a safety issue:
+\begin{cfa}
+char * p = "abc";
+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[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
+\end{description}
+\item
+\begin{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}§
+\end{cfa}
+is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
+This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example,
+\begin{cfa}
+struct X { int i; struct X *next; };
+static struct X a;                              §\C{// forward definition}§
+static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
+static struct X a = { 1, &b };  §\C{// definition}§
+\end{cfa}
+\item[Rationale:] avoids having different initialization rules for builtin types and user-defined types.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] the initializer for one of a set of mutually-referential file-local static objects must invoke a routine call to achieve the initialization.
+\item[How widely used:] seldom
+\end{description}
+\item
+\begin{description}
+\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)}§
+        };
+        ®.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}§
+\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.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] Semantic transformation.
+\item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
+\end{description}
+\item
+\begin{description}
+\item[Change:] In C++, the name of a nested class is local to its enclosing class.
+\item[Rationale:] C++ classes have member functions which require that classes establish scopes.
+\item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
+\begin{cfa}
+struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
+struct X {
+        struct Y { /* ... */ } y;
+};
+\end{cfa}
+All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct.
+Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
+\item[How widely used:] Seldom.
+\end{description}
+\item
+\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[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[How widely used:] seldom.
+\end{description}
+\end{enumerate}
 \section{Standard Headers}
 \label{s:StandardHeaders}
 C11 prescribes the following standard header-files~\cite[\S~7.1.2]{C11} and \CFA adds to this list:
+\Celeven prescribes the following standard header-files~\cite[\S~7.1.2]{C11} and \CFA adds to this list:
 \begin{quote2}
+\begin{tabular}{lll|l}
+\multicolumn{3}{c|}{C11} & \multicolumn{1}{c}{\CFA}             \\
+\lstset{deletekeywords={float}}
+\begin{tabular}{@{}llll|l@{}}
+\multicolumn{4}{c|}{C11} & \multicolumn{1}{c}{\CFA}             \\
 \hline
+assert.h        & math.h                & stdlib.h              & unistd.h      \\
+complex.h       & setjmp.h              & stdnoreturn.h & gmp.h         \\
+ctype.h         & signal.h              & string.h              \\
+errno.h         & stdalign.h    & tgmath.h              \\
+fenv.h          & stdarg.h              & threads.h             \\
+float.h         & stdatomic.h   & time.h                \\
+inttypes.h      & stdbool.h             & uchar.h               \\
+iso646.h        & stddef.h              & wchar.h               \\
+limits.h        & stdint.h              & wctype.h              \\
+locale.h        & stdio.h               &                               \\
+\begin{tabular}{@{}l@{}}
+\Indexc{assert.h}               \\
+\Indexc{complex.h}              \\
+\Indexc{ctype.h}                \\
+\Indexc{errno.h}                \\
+\Indexc{fenv.h}                 \\
+\Indexc{float.h}                \\
+\Indexc{inttypes.h}             \\
+\Indexc{iso646.h}               \\
+\end{tabular}
+&
+\begin{tabular}{@{}l@{}}
+\Indexc{limits.h}               \\
+\Indexc{locale.h}               \\
+\Indexc{math.h}                 \\
+\Indexc{setjmp.h}               \\
+\Indexc{signal.h}               \\
+\Indexc{stdalign.h}             \\
+\Indexc{stdarg.h}               \\
+\Indexc{stdatomic.h}    \\
+\end{tabular}
+&
+\begin{tabular}{@{}l@{}}
+\Indexc{stdbool.h}              \\
+\Indexc{stddef.h}               \\
+\Indexc{stdint.h}               \\
+\Indexc{stdio.h}                \\
+\Indexc{stdlib.h}               \\
+\Indexc{stdnoreturn.h}  \\
+\Indexc{string.h}               \\
+\Indexc{tgmath.h}               \\
+\end{tabular}
+&
+\begin{tabular}{@{}l@{}}
+\Indexc{threads.h}              \\
+\Indexc{time.h}                 \\
+\Indexc{uchar.h}                \\
+\Indexc{wchar.h}                \\
+\Indexc{wctype.h}               \\
+                                                \\
+                                                \\
+                                                \\
+\end{tabular}
+&
+\begin{tabular}{@{}l@{}}
+\Indexc{unistd.h}               \\
+\Indexc{gmp.h}                  \\
+                                                \\
+                                                \\
+                                                \\
+                                                \\
+                                                \\
+                                                \\
+\end{tabular}
 \end{tabular}
 \end{quote2}
 For the prescribed head-files, \CFA implicitly wraps their 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.
 …
 \label{s:StandardLibrary}
+The goal of the \CFA standard-library is to wrap many of the existing C library-routines that are explicitly polymorphic into implicitly polymorphic versions.
+\subsection{malloc}
+The \CFA standard-library wraps explicitly-polymorphic C routines into implicitly-polymorphic versions.
+\subsection{Storage Management}
+The storage-management routines extend their C equivalents by overloading, alternate names, providing shallow type-safety, and removing the need to specify the allocation size for non-array types.
+Storage management provides the following capabilities:
+\begin{description}
+\item[fill]
+after allocation the storage is filled with a specified character.
+\item[resize]
+an existing allocation is decreased or increased in size.
+In either case, new storage may or may not be allocated and, if there is a new allocation, as much data from the existing allocation is copied.
+For an increase in storage size, new storage after the copied data may be filled.
+\item[alignment]
+an allocation starts on a specified memory boundary, e.g., an address multiple of 64 or 128 for cache-line purposes.
+\item[array]
+the allocation size is scaled to the specified number of array elements.
+An array may be filled, resized, or aligned.
+\end{description}
+The table shows allocation routines supporting different combinations of storage-management capabilities:
+\begin{center}
+\begin{tabular}{@{}lr|l|l|l|l@{}}
+                &                                       & \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   \\
+\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.
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
+forall( otype T ) T * malloc( void );§\indexc{malloc}§
+forall( otype T ) T * malloc( char fill );
+forall( otype T ) T * malloc( T * ptr, size_t size );
+forall( otype T ) T * malloc( T * ptr, size_t size, unsigned char fill );
+forall( otype T ) T * calloc( size_t nmemb );§\indexc{calloc}§
+forall( otype T ) T * realloc( T * ptr, size_t size );§\indexc{ato}§
+forall( otype T ) T * realloc( T * ptr, size_t size, unsigned char fill );
+forall( otype T ) T * aligned_alloc( size_t alignment );§\indexc{ato}§
+forall( otype T ) T * memalign( size_t alignment );             // deprecated
+forall( otype T ) int posix_memalign( T ** ptr, size_t alignment );
+forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill
+forall( otype T ) T * memset( T * ptr );                                // remove when default value available
+\end{cfa}
+\subsection{ato / strto}
+// 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
+forall( dtype T | sized(T) ) T * malloc( void );
+forall( dtype T | sized(T) ) T * calloc( size_t dim );
+forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size );
+forall( dtype T | sized(T) ) T * memalign( size_t align );
+forall( dtype T | sized(T) ) T * aligned_alloc( size_t align );
+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}§
+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( size_t dim, char fill );
+forall( dtype T | sized(T) ) T * alloc( T ptr[], size_t dim );
+forall( dtype T | sized(T) ) T * alloc( T ptr[], size_t dim, char fill );
+// §\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 );
+forall( dtype T | sized(T) ) T * align_alloc( size_t align, size_t dim );
+forall( dtype T | sized(T) ) T * align_alloc( size_t align, size_t dim, char fill );
+// C unsafe initialization/copy
+extern "C" {
+void * memset( void * dest, int c, size_t size );
+void * memcpy( void * dest, const void * src, size_t size );
+}
+// §\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}§
+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}§
+forall( dtype T | sized(T) | { void ^?{}( T * ); }, ttype Params | { void adelete( Params ); } )
+  void adelete( size_t dim, T arr[], Params rest );
+\end{cfa}
+\subsection{Conversion}
 \leavevmode
 …
 \subsection{bsearch / qsort}
+\subsection{Search / Sort}
 \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}§
+unsigned int bsearch( T key, const T * arr, size_t dim );
 forall( otype T | { int ?<?( T, T ); } )
+T * bsearch( const T key, const T * arr, size_t dimension );§\indexc{bsearch}§
+forall( otype T | { int ?<?( T, T ); } )
+void qsort( const T * arr, size_t dimension );§\indexc{qsort}§
+\end{cfa}
+\subsection{abs}
+void qsort( const T * arr, size_t dim );§\indexc{qsort}§
+\end{cfa}
+\subsection{Absolute Value}
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 char abs( char );§\indexc{abs}§
+unsigned char abs( signed char );§\indexc{abs}§
 int abs( int );
 long int abs( long int );
 long long int abs( long long int );
+unsigned long int abs( long int );
+unsigned long long int abs( long long int );
 float abs( float );
 double abs( double );
 …
 double abs( double _Complex );
 long double abs( long double _Complex );
+\end{cfa}
+\subsection{random}
+forall( otype T | { void ?{}( T *, zero_t ); int ?<?( T, T ); T -?( T ); } )
+T abs( T );
+\end{cfa}
+\subsection{Random Numbers}
 \leavevmode
 …
 \subsection{min / max / clamp / swap}
+\subsection{Algorithms}
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
+forall( otype T | { int ?<?( T, T ); } )
+T min( const T t1, const T t2 );§\indexc{min}§
+forall( otype T | { int ?>?( T, T ); } )
+T max( const T t1, const 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}
 …
 \label{s:Math Library}
 The goal of the \CFA math-library is to wrap many of the existing C math library-routines that are explicitly polymorphic into implicitly polymorphic versions.
+The \CFA math-library wraps explicitly-polymorphic C math-routines into implicitly-polymorphic versions.
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
-float fabs( float );§\indexc{fabs}§
-double fabs( double );
-long double fabs( long double );
-float cabs( float _Complex );
-double cabs( double _Complex );
-long double cabs( long double _Complex );
 float ?%?( float, float );§\indexc{fmod}§
 float fmod( float, float );
 …
+\section{Multi-precision Integers}
+\label{s:MultiPrecisionIntegers}
+\CFA has an interface to the GMP \Index{multi-precision} signed-integers~\cite{GMP}, similar to the \CC interface provided by GMP.
+The \CFA interface wraps GMP routines into operator routines to make programming with multi-precision integers identical to using fixed-sized integers.
+The \CFA type name for multi-precision signed-integers is \Indexc{Int} and the header file is \Indexc{gmp}.
+\begin{cfa}
+void ?{}( Int * this );                                 §\C{// constructor}§
+void ?{}( Int * this, Int init );
+void ?{}( Int * this, zero_t );
+void ?{}( Int * this, one_t );
+void ?{}( Int * this, signed long int init );
+void ?{}( Int * this, unsigned long int init );
+void ?{}( Int * this, const char * val );
+void ^?{}( Int * this );
+Int ?=?( Int * lhs, Int rhs );                  §\C{// assignment}§
+Int ?=?( Int * lhs, long int rhs );
+Int ?=?( Int * lhs, unsigned long int rhs );
+Int ?=?( Int * lhs, const char * rhs );
+char ?=?( char * lhs, Int rhs );
+short int ?=?( short int * lhs, Int rhs );
+int ?=?( int * lhs, Int rhs );
+long int ?=?( long int * lhs, Int rhs );
+unsigned char ?=?( unsigned char * lhs, Int rhs );
+unsigned short int ?=?( unsigned short int * lhs, Int rhs );
+unsigned int ?=?( unsigned int * lhs, Int rhs );
+unsigned long int ?=?( unsigned long int * lhs, Int rhs );
+long int narrow( Int val );
+unsigned long int narrow( Int val );
+int ?==?( Int oper1, Int oper2 );               §\C{// comparison}§
+int ?==?( Int oper1, long int oper2 );
+int ?==?( long int oper2, Int oper1 );
+int ?==?( Int oper1, unsigned long int oper2 );
+int ?==?( unsigned long int oper2, Int oper1 );
+int ?!=?( Int oper1, Int oper2 );
+int ?!=?( Int oper1, long int oper2 );
+int ?!=?( long int oper1, Int oper2 );
+int ?!=?( Int oper1, unsigned long int oper2 );
+int ?!=?( unsigned long int oper1, Int oper2 );
+int ?<?( Int oper1, Int oper2 );
+int ?<?( Int oper1, long int oper2 );
+int ?<?( long int oper2, Int oper1 );
+int ?<?( Int oper1, unsigned long int oper2 );
+int ?<?( unsigned long int oper2, Int oper1 );
+int ?<=?( Int oper1, Int oper2 );
+int ?<=?( Int oper1, long int oper2 );
+int ?<=?( long int oper2, Int oper1 );
+int ?<=?( Int oper1, unsigned long int oper2 );
+int ?<=?( unsigned long int oper2, Int oper1 );
+int ?>?( Int oper1, Int oper2 );
+int ?>?( Int oper1, long int oper2 );
+int ?>?( long int oper1, Int oper2 );
+int ?>?( Int oper1, unsigned long int oper2 );
+int ?>?( unsigned long int oper1, Int oper2 );
+int ?>=?( Int oper1, Int oper2 );
+int ?>=?( Int oper1, long int oper2 );
+int ?>=?( long int oper1, Int oper2 );
+int ?>=?( Int oper1, unsigned long int oper2 );
+int ?>=?( unsigned long int oper1, Int oper2 );
+Int +?( Int oper );                                             §\C{// arithmetic}§
+Int -?( Int oper );
+Int ~?( Int oper );
+Int ?&?( Int oper1, Int oper2 );
+Int ?&?( Int oper1, long int oper2 );
+Int ?&?( long int oper1, Int oper2 );
+Int ?&?( Int oper1, unsigned long int oper2 );
+Int ?&?( unsigned long int oper1, Int oper2 );
+Int ?&=?( Int * lhs, Int rhs );
+Int ?|?( Int oper1, Int oper2 );
+Int ?|?( Int oper1, long int oper2 );
+Int ?|?( long int oper1, Int oper2 );
+Int ?|?( Int oper1, unsigned long int oper2 );
+Int ?|?( unsigned long int oper1, Int oper2 );
+Int ?|=?( Int * lhs, Int rhs );
+Int ?^?( Int oper1, Int oper2 );
+Int ?^?( Int oper1, long int oper2 );
+Int ?^?( long int oper1, Int oper2 );
+Int ?^?( Int oper1, unsigned long int oper2 );
+Int ?^?( unsigned long int oper1, Int oper2 );
+Int ?^=?( Int * lhs, Int rhs );
+Int ?+?( Int addend1, Int addend2 );
+Int ?+?( Int addend1, long int addend2 );
+Int ?+?( long int addend2, Int addend1 );
+Int ?+?( Int addend1, unsigned long int addend2 );
+Int ?+?( unsigned long int addend2, Int addend1 );
+Int ?+=?( Int * lhs, Int rhs );
+Int ?+=?( Int * lhs, long int rhs );
+Int ?+=?( Int * lhs, unsigned long int rhs );
+Int ++?( Int * lhs );
+Int ?++( Int * lhs );
+Int ?-?( Int minuend, Int subtrahend );
+Int ?-?( Int minuend, long int subtrahend );
+Int ?-?( long int minuend, Int subtrahend );
+Int ?-?( Int minuend, unsigned long int subtrahend );
+Int ?-?( unsigned long int minuend, Int subtrahend );
+Int ?-=?( Int * lhs, Int rhs );
+Int ?-=?( Int * lhs, long int rhs );
+Int ?-=?( Int * lhs, unsigned long int rhs );
+Int --?( Int * lhs );
+Int ?--( Int * lhs );
+Int ?*?( Int multiplicator, Int multiplicand );
+Int ?*?( Int multiplicator, long int multiplicand );
+Int ?*?( long int multiplicand, Int multiplicator );
+Int ?*?( Int multiplicator, unsigned long int multiplicand );
+Int ?*?( unsigned long int multiplicand, Int multiplicator );
+Int ?*=?( Int * lhs, Int rhs );
+Int ?*=?( Int * lhs, long int rhs );
+Int ?*=?( Int * lhs, unsigned long int rhs );
+Int ?/?( Int dividend, Int divisor );
+Int ?/?( Int dividend, unsigned long int divisor );
+Int ?/?( unsigned long int dividend, Int divisor );
+Int ?/?( Int dividend, long int divisor );
+Int ?/?( long int dividend, Int divisor );
+Int ?/=?( Int * lhs, Int rhs );
+Int ?/=?( Int * lhs, long int rhs );
+Int ?/=?( Int * lhs, unsigned long int rhs );
+[ Int, Int ] div( Int dividend, Int divisor );
+[ Int, Int ] div( Int dividend, unsigned long int divisor );
+Int ?%?( Int dividend, Int divisor );
+Int ?%?( Int dividend, unsigned long int divisor );
+Int ?%?( unsigned long int dividend, Int divisor );
+Int ?%?( Int dividend, long int divisor );
+Int ?%?( long int dividend, Int divisor );
+Int ?%=?( Int * lhs, Int rhs );
+Int ?%=?( Int * lhs, long int rhs );
+Int ?%=?( Int * lhs, unsigned long int rhs );
+Int ?<<?( Int shiften, mp_bitcnt_t shift );
+Int ?<<=?( Int * lhs, mp_bitcnt_t shift );
+Int ?>>?( Int shiften, mp_bitcnt_t shift );
+Int ?>>=?( Int * lhs, mp_bitcnt_t shift );
+Int abs( Int oper );                                    §\C{// number functions}§
+Int fact( unsigned long int N );
+Int gcd( Int oper1, Int oper2 );
+Int pow( Int base, unsigned long int exponent );
+Int pow( unsigned long int base, unsigned long int exponent );
+void srandom( gmp_randstate_t state );
+Int random( gmp_randstate_t state, mp_bitcnt_t n );
+Int random( gmp_randstate_t state, Int n );
+Int random( gmp_randstate_t state, mp_size_t max_size );
+int sgn( Int oper );
+Int sqrt( Int oper );
+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}
+The following factorial programs contrast using GMP with the \CFA and C interfaces, where the output from these programs appears in \VRef[Figure]{f:MultiPrecisionFactorials}.
+(Compile with flag \Indexc{-lgmp} to link with the GMP library.)
+\begin{quote2}
+\begin{tabular}{@{}l@{\hspace{\parindentlnth}}|@{\hspace{\parindentlnth}}l@{}}
+\multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{@{\hspace{\parindentlnth}}c}{\textbf{C}}      \\
+\hline
+\begin{cfa}
+#include <gmp>§\indexc{gmp}§
+int main( void ) {
+        sout | "Factorial Numbers" | endl;
+        Int fact = 1;
+        sout | 0 | fact | endl;
+        for ( unsigned int i = 1; i <= 40; i += 1 ) {
+                fact *= i;
+                sout | i | fact | endl;
+        }
+}
+\end{cfa}
+&
+\begin{cfa}
+#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 );
+        for ( unsigned int i = 1; i <= 40; i += 1 ) {
+                ®mpz_mul_ui®( fact, fact, i );
+                ®gmp_printf®( "%d %Zd\n", i, fact );
+        }
+}
+\end{cfa}
+\end{tabular}
+\end{quote2}
+\begin{figure}
+\begin{cfa}
+Factorial Numbers
+1
+1
+2
+6
+24
+120
+720
+5040
+40320
+362880
+3628800
+39916800
+479001600
+6227020800
+87178291200
+1307674368000
+20922789888000
+355687428096000
+6402373705728000
+121645100408832000
+2432902008176640000
+51090942171709440000
+1124000727777607680000
+25852016738884976640000
+620448401733239439360000
+15511210043330985984000000
+403291461126605635584000000
+10888869450418352160768000000
+304888344611713860501504000000
+8841761993739701954543616000000
+265252859812191058636308480000000
+8222838654177922817725562880000000
+263130836933693530167218012160000000
+8683317618811886495518194401280000000
+295232799039604140847618609643520000000
+10333147966386144929666651337523200000000
+371993326789901217467999448150835200000000
+13763753091226345046315979581580902400000000
+523022617466601111760007224100074291200000000
+20397882081197443358640281739902897356800000000
+815915283247897734345611269596115894272000000000
+\end{cfa}
+\caption{Multi-precision Factorials}
+\label{f:MultiPrecisionFactorials}
+\end{figure}
 \section{Rational Numbers}
 \label{s:RationalNumbers}
 …
 }; // Rational
+// constants
+extern struct Rational 0;
+extern struct Rational 1;
+// constructors
+Rational rational();
+Rational rational();                                    §\C{// constructors}§
 Rational rational( long int n );
 Rational rational( long int n, long int d );
+// getter/setter for numerator/denominator
+long int numerator( Rational r );
+void ?{}( Rational * r, zero_t );
+void ?{}( Rational * r, one_t );
+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 );
+// comparison
+int ?==?( Rational l, Rational r );
+int ?==?( Rational l, Rational r );             §\C{// comparison}§
 int ?!=?( Rational l, Rational r );
 int ?<?( Rational l, Rational r );
 …
 int ?>=?( Rational l, Rational r );
+// arithmetic
+Rational -?( Rational r );
+Rational -?( Rational r );                              §\C{// arithmetic}§
 Rational ?+?( Rational l, Rational r );
 Rational ?-?( Rational l, Rational r );
 …
 Rational ?/?( Rational l, Rational r );
+// conversion
+double widen( Rational r );
+double widen( Rational r );                             §\C{// conversion}§
 Rational narrow( double f, long int md );
+// I/O
+forall( dtype istype | istream( istype ) ) istype * ?|?( istype *, Rational * );
+forall( dtype istype | istream( istype ) ) istype * ?|?( istype *, Rational * ); // I/O
 forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype *, Rational );
 \end{cfa}

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

Context Navigation

Changeset b1e63ac5 for doc/user/user.tex

Legend:

doc/user/user.tex

Download in other formats: