Index: doc/bibliography/cfa.bib
===================================================================
--- doc/bibliography/cfa.bib	(revision 4203f71b5852a52f2a4817e35a8ec4100c1ac7f7)
+++ doc/bibliography/cfa.bib	(revision 02153febd80045a0fdce301fb0f003053d5fa36c)
@@ -862,12 +862,12 @@
 }
 
-@techreport{C11,
-    type	= {International Standard},
+@manual{C11,
     keywords	= {ISO/IEC C 11},
     contributer	= {pabuhr@plg},
-    key		= {{ISO/IEC} 9889-2011},
-    title	= {American National Standard Information technology -- Programming Languages -- {C}},
-    institution = {International Standard Organization},
-    address	= {http://www.iso.org},
+    author	= {C11},
+    title	= {Programming Languages -- {C} {ISO/IEC} 9889:2011},
+    edition	= {3rd},
+    publisher	= {International Standard Organization},
+    address	= {\href{https://www.iso.org/standard/57853.html}{https://\-www.iso.org/\-standard/\-57853.html}},
     year	= 2012,
 }
@@ -877,9 +877,8 @@
     keywords	= {ISO/IEC TS 19217:2015},
     contributer	= {a3moss@uwaterloo.ca},
-    key		= {{ISO/IEC} {TS} 19217},
     author	= {Concepts},
-    title	= {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts},
-    institution	= {International Standard Organization},
-    address	= {http://www.iso.org},
+    title	= {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts {ISO/IEC} {TS} 19217:2015},
+    publisher	= {International Standard Organization},
+    address	= {\href{https://www.iso.org/standard/64031.html}{https://\-www.iso.org/\-standard/\-64031.html}},
     year	= 2015
 }
@@ -1096,10 +1095,9 @@
     keywords	= {ISO/IEC Cobol 14},
     contributer	= {pabuhr@plg},
-    key		= {Cobol14},
-    title	= {Programming Languages -- {Cobol}},
+    author	= {Cobol14},
+    title	= {Programming Languages -- {Cobol} ISO/IEC 1989:2014},
     edition	= {2nd},
-    organization= {International Standard ISO/IEC 1989:2014},
-    publisher   = {International Standard Organization},
-    address	= {http://www.iso.org},
+    institution = {International Standard Organization},
+    address	= {\href{https://www.iso.org/standard/51416.html}{https://\-www.iso.org/\-standard/\-51416.html}},
     year	= 2014,
 }
@@ -2836,9 +2834,9 @@
     keywords	= {ISO/IEC Fortran 08},
     contributer	= {pabuhr@plg},
-    key		= {Fortran08},
-    title	= {Programming Languages -- {Fortran} Part 1},
-    organization= {International Standard ISO/IEC 1989:2014},
+    author	= {Fortran08},
+    title	= {Programming Languages -- {Fortran} Part 1:Base Language ISO/IEC 1539-1:2010},
+    edition	= {3rd},
     publisher   = {International Standard Organization},
-    address	= {http://www.iso.org},
+    address	= {\href{https://www.iso.org/standard/50459.html}{https://\-www.iso.org/\-standard/\-50459.html}},
     year	= 2010,
 }
@@ -5359,13 +5357,12 @@
 }
 
-@manual{ANSI14:C++,
+@manual{C++14,
     keywords	= {ISO/IEC C++ 14},
     contributer	= {pabuhr@plg},
-    key		= {C++14},
-    title	= {Programming Languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}},
+    author	= {C++14},
+    title	= {Programming Languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} ISO/IEC 14882:2014},
     edition	= {4th},
-    organization= {International Standard ISO/IEC 14882:2014 (E)},
     publisher   = {International Standard Organization},
-    address	= {http://www.iso.org},
+    address	= {\href{https://www.iso.org/standard/64029.html}{https://\-www.iso.org/\-standard/\-64029.html}},
     year	= 2014,
 }
@@ -5706,11 +5703,11 @@
 
 @manual{Ada12,
-    keywords	= {Ada},
-    contributer	= {pabuhr@plg},
-    title	= {Programming languages -- {Ada}},
+    keywords	= {ISO/IEC Ada},
+    contributer	= {pabuhr@plg},
+    author	= {Ada12},
+    title	= {Programming languages -- {Ada} ISO/IEC 8652:2012},
     edition	= {3rd},
-    organization= {International Standard ISO/IEC 1989:2014},
     publisher   = {International Standard Organization},
-    address	= {http://www.iso.org},
+    address	= {\href{https://www.iso.org/standard/61507.html}{https://\-www.iso.org/\-standard/\-61507.html}},
     year	= 2012,
 }
Index: doc/user/pointer2.fig
===================================================================
--- doc/user/pointer2.fig	(revision 4203f71b5852a52f2a4817e35a8ec4100c1ac7f7)
+++ doc/user/pointer2.fig	(revision 02153febd80045a0fdce301fb0f003053d5fa36c)
@@ -8,40 +8,42 @@
 -2
 1200 2
+6 1125 2100 3525 2400
 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
-	 1500 1950 1950 1950 1950 2250 1500 2250 1500 1950
+	 1500 2100 1950 2100 1950 2400 1500 2400 1500 2100
+2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
+	 2700 2100 3150 2100 3150 2400 2700 2400 2700 2100
+4 2 0 100 0 4 10 0.0000 2 120 270 1425 2400 104\001
+4 2 0 100 0 4 10 0.0000 2 120 90 1425 2225 y\001
+4 0 0 100 0 4 10 0.0000 2 120 165 2025 2300 int\001
+4 2 0 100 0 4 10 0.0000 2 120 270 2625 2400 112\001
+4 2 0 100 0 4 10 0.0000 2 150 180 2625 2225 p2\001
+4 1 0 100 0 4 10 0.0000 2 120 90 1725 2300 3\001
+4 0 0 100 0 4 10 0.0000 2 120 270 3225 2300 int *\001
+4 1 0 100 0 4 10 0.0000 2 120 270 2925 2300 100\001
+-6
 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
 	 1500 1500 1950 1500 1950 1800 1500 1800 1500 1500
 2 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2
 	1 1 1.00 45.00 90.00
-	 2700 1800 1950 1950
+	 2700 1800 1950 2100
 2 1 0 1 4 7 50 -1 -1 0.000 0 0 -1 1 0 2
 	1 1 1.00 45.00 90.00
-	 2700 1950 1950 1800
-2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
-	 2700 1950 3150 1950 3150 2250 2700 2250 2700 1950
+	 2700 2100 1950 1800
 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
 	 2700 1500 3150 1500 3150 1800 2700 1800 2700 1500
 2 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2
 	1 1 1.00 45.00 90.00
-	 3900 1800 3150 1950
+	 3900 1800 3150 2100
 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
 	 3900 1500 4350 1500 4350 1800 3900 1800 3900 1500
-4 2 0 100 0 4 10 0.0000 2 120 270 1425 2250 104\001
 4 2 0 100 0 4 10 0.0000 2 120 270 1425 1800 100\001
 4 2 0 100 0 4 10 0.0000 2 90 90 1425 1625 x\001
-4 2 0 100 0 4 10 0.0000 2 120 90 1425 2075 y\001
-4 0 0 100 0 4 10 0.0000 2 120 165 2025 2150 int\001
 4 0 0 100 0 4 10 0.0000 2 120 165 2025 1700 int\001
-4 2 0 100 0 4 10 0.0000 2 120 270 2625 2250 112\001
-4 2 0 100 0 4 10 0.0000 2 150 180 2625 2075 p2\001
 4 2 0 100 0 4 10 0.0000 2 120 270 2625 1800 108\001
 4 2 0 100 0 4 10 0.0000 2 150 180 2625 1625 p1\001
-4 1 0 100 0 4 10 0.0000 2 120 90 1725 2150 3\001
 4 1 0 100 0 4 10 0.0000 2 120 90 1725 1700 3\001
-4 0 0 100 0 4 10 0.0000 2 120 270 3225 2150 int *\001
 4 0 0 100 0 4 10 0.0000 2 120 270 3225 1700 int *\001
 4 2 0 100 0 4 10 0.0000 2 120 270 3825 1800 116\001
 4 2 0 100 0 4 10 0.0000 2 150 180 3825 1625 p3\001
-4 1 0 100 0 4 10 0.0000 2 120 270 2925 2150 100\001
 4 1 0 100 0 4 10 0.0000 2 120 270 2925 1700 104\001
 4 1 0 100 0 4 10 0.0000 2 120 270 4125 1700 112\001
Index: doc/user/user.tex
===================================================================
--- doc/user/user.tex	(revision 4203f71b5852a52f2a4817e35a8ec4100c1ac7f7)
+++ doc/user/user.tex	(revision 02153febd80045a0fdce301fb0f003053d5fa36c)
@@ -11,6 +11,6 @@
 %% 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 : Wed May 17 22:42:11 2017
+%% Update Count     : 1685
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -94,5 +94,5 @@
 \author{
 \huge \CFA Team \medskip \\
-\Large Peter A. Buhr, Richard Bilson, Thierry Delisle, \smallskip \\
+\Large Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\
 \Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Rob Schluntz
 }% author
@@ -217,5 +217,5 @@
 
 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.}
@@ -514,5 +514,5 @@
 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.
+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@{}}
@@ -659,18 +659,20 @@
 
 
-\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 a 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 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;
@@ -691,14 +693,17 @@
 \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}
 &
@@ -711,12 +716,12 @@
 \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 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 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, \eg:
 \begin{quote2}
-\begin{tabular}{@{}ll@{}}
+\begin{tabular}{@{}l@{\hspace{2em}}l@{}}
 \begin{cfa}
 int x, y, ®*® p1, ®*® p2, ®**® p3;
@@ -727,28 +732,29 @@
 \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:
+In many cases, a compiler might be able to infer the best meaning for these two cases.
+For example, \Index*{Algol68}~\cite{Algol68} inferences 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 deferencing ©*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 dereference inferencing, 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\ \ *p1 = *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 works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
 
 However, in most other situations, the pointed-to value is requested more often than the pointer address.
@@ -762,5 +768,5 @@
 \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.
 \begin{cfa}
 int x, y, ®&® r1, ®&® r2, ®&&® r3;
@@ -773,9 +779,5 @@
 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);
@@ -793,5 +795,7 @@
 (&(&®*®)®*®)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.
+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,
@@ -805,13 +809,8 @@
 &&&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:
+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 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;}§
@@ -819,15 +818,21 @@
 ®&®cr = &cx;					§\C{// can change cr}§
 cr = 7;							§\C{// error, cannot change cx}§
-int & const rc = x;				§\C{// must be initialized, \CC reference}§
+int & const rc = x;				§\C{// must be initialized}§
 ®&®rc = &x;						§\C{// error, cannot change rc}§
-const int & const crc = cx;		§\C{// must be initialized, \CC reference}§
+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 ©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.
+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 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 addressing errors because of explicit storage-management:
+\begin{cfa}
+int & const cr = *malloc();
+delete &cr;
+cr = 7;							§\C{// unsound pointer dereference}§
+\end{cfa}
+
 Finally, 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;
@@ -849,13 +854,17 @@
 where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}).
 
+In contract 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}.
+\Index*{Java}'s reference types to objects (because 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.
+
 \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 * p = &x;					§\C{// both \&x and x are possible interpretations in C}§
 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.
+C allows ©p© to be assigned with ©&x© or ©x© (many compilers warn about the latter assignment).
+\CFA allows ©r© to be assigned ©x© only because it inferences a dereference for ©x©, by implicitly inserting a address-of operator, ©&©, before the initialization expression because a reference behaves like the variable name it is pointing-to.
+Similarly, when a reference 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 & rp );			§\C{// reference parameter and return}§
@@ -863,5 +872,5 @@
 \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.
+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.
 
 When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
@@ -873,5 +882,5 @@
 \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.)
+(The ©&© is necessary for the pointer-type 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}
@@ -885,5 +894,5 @@
 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).
+While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine objects in an inconsistent way: a routine object is both a pointer and a reference (particle and wave).
 \begin{cfa}
 void f( int p ) {...}
@@ -893,5 +902,5 @@
 fp(3);							§\C{// reference invocation}§
 \end{cfa}
-A routine variable is best described by a ©const© reference:
+A routine object is best described by a ©const© reference:
 \begin{cfa}
 const void (&fp)( int ) = f;
@@ -900,7 +909,179 @@
 &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{
+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.
+\CFA allows this additional use of references for routine objects in an attempt to give a more consistent meaning for them.
+
+
+\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.
+
+
+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.
+
+20 C provides a pointer type; CFA adds a reference type. Both types contain an address, which is normally a
+21 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.
+
+21 Special addresses are used to denote certain states or access co-processor memory. By
+22 convention, no variable is placed at address 0, so addresses like 0, 1, 2, 3 are often used to denote no-value
+23 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.
+
+23 Often dereferencing a special state causes a memory fault, so checking is necessary
+24 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.
+
+24 If the programming language assigns addresses, a program's execution is sound, \ie all
+25 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.
+
+1 Program variables are implicit pointers to memory locations generated by the compiler and automatically
+2 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.
+
+13 A pointer/reference is a generalization of a variable name, \ie a mutable address that can point to more
+14 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.
+
+16 not occupy storage as the literal is embedded directly into instructions.) Hence, a pointer occupies memory
+17 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.
+
+21 p2 = p1 + x; // compiler infers *p2 = *p1 + x;
+
+What language are we in now?
+
+24 pointer usage. However, in C, the following cases are ambiguous, especially with pointer arithmetic:
+25 p1 = p2; // p1 = p2 or *p1 = *p2
+
+This isn't ambiguous. it's defined to be the first option.
+
+26 p1 = p1 + 1; // p1 = p1 + 1 or *p1 = *p1 + 1
+
+Again, this statement is not ambiguous.
+
+13 example. Hence, a reference behaves like the variable name for the current variable it is pointing-to. The
+14 simplest way to understand a reference is to imagine the compiler inserting a dereference operator before
+15 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).
+
+24 Cancellation works to arbitrary depth, and pointer and reference values are interchangeable because both
+25 contain addresses.
+
+Except they're not interchangeable, because they have different and incompatible types.
+
+40 Interestingly, C++ deals with the address duality by making the pointed-to value the default, and prevent-
+41 ing changes to the reference address, which eliminates half of the duality. Java deals with the address duality
+42 by making address assignment the default and requiring field assignment (direct or indirect via methods),
+43 \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.)
+
+11 Hence, for type & const, there is no pointer assignment, so &rc = &x is disallowed, and the address value
+12 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.
+
+12 In effect, the compiler is managing the
+13 addresses for type & const not the programmer, and by a programming discipline of only using references
+14 with references, address errors can be prevented.
+
+Again, is this assuming automatic storage management?
+
+18 rary binding. For reference initialization (like pointer), the initializing value must be an address (lvalue) not
+19 a value (rvalue).
+
+This sentence appears to suggest that an address and an lvalue are the same thing.
+
+20 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.
+
+21 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?
+
+22 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.
+
+22 Similarly,
+23 when a reference is used for a parameter/return type, the call-site argument does not require a reference
+24 operator.
+
+Furthermore, it would not be correct to use a reference operator.
+
+45 The implicit conversion allows
+1 seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call.
+2 While C' attempts to handle pointers and references in a uniform, symmetric manner, C handles routine
+3 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}
 
 
@@ -1353,8 +1534,8 @@
 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.
@@ -1373,5 +1554,5 @@
 [ 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).
@@ -1429,5 +1610,5 @@
 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}
@@ -1442,6 +1623,6 @@
 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;
@@ -1481,5 +1662,5 @@
 ©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 ];
@@ -1516,5 +1697,5 @@
 \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.
@@ -1604,5 +1785,5 @@
 [ x1, y1 ] = z = 0;
 \end{cfa}
-As in C, the rightmost assignment is performed first, i.e., assignment parses right to left.
+As in C, the rightmost assignment is performed first, \ie assignment parses right to left.
 
 
@@ -1669,5 +1850,5 @@
 
 
-\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.
@@ -1766,5 +1947,5 @@
 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.
 
 
@@ -1903,5 +2084,5 @@
 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}
 
@@ -1911,5 +2092,5 @@
 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,
@@ -1921,5 +2102,5 @@
 \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: ...
@@ -2173,5 +2354,5 @@
 
 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.
+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}§
@@ -2186,5 +2367,5 @@
 12 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.
+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}§
@@ -2461,19 +2642,4 @@
 \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}
 
 
@@ -4683,5 +4849,5 @@
 \section{Incompatible}
 
-The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
+The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{C++14}.
 
 \begin{enumerate}
@@ -4781,5 +4947,5 @@
 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.
+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 ``©::©''.
@@ -4878,5 +5044,5 @@
 \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.
@@ -4886,5 +5052,5 @@
 \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.
+The \CFA standard-library wraps many existing explicitly-polymorphic C general-routines into implicitly-polymorphic versions.
 
 
@@ -5010,5 +5176,5 @@
 \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 many existing explicitly-polymorphic C math-routines into implicitly-polymorphic versions.
 
 
Index: src/Parser/ExpressionNode.cc
===================================================================
--- src/Parser/ExpressionNode.cc	(revision 4203f71b5852a52f2a4817e35a8ec4100c1ac7f7)
+++ src/Parser/ExpressionNode.cc	(revision 02153febd80045a0fdce301fb0f003053d5fa36c)
@@ -10,6 +10,6 @@
 // Created On       : Sat May 16 13:17:07 2015
 // Last Modified By : Peter A. Buhr
-// Last Modified On : Thu Mar 30 17:02:46 2017
-// Update Count     : 515
+// Last Modified On : Wed May 17 21:31:01 2017
+// Update Count     : 527
 //
 
@@ -207,6 +207,8 @@
 } // build_field_name_fraction_constants
 
+
+
 Expression * build_field_name_REALFRACTIONconstant( const std::string & str ) {
-	assert( str[0] == '.' );
+	if ( str.find_first_not_of( "0123456789", 1 ) != string::npos ) throw SemanticError( "invalid tuple index " + str );
 	Expression * ret = build_constantInteger( *new std::string( str.substr(1) ) );
 	delete &str;
@@ -215,5 +217,5 @@
 
 Expression * build_field_name_REALDECIMALconstant( const std::string & str ) {
-	assert( str[str.size()-1] == '.' );
+	if ( str[str.size()-1] != '.' ) throw SemanticError( "invalid tuple index " + str );
 	Expression * ret = build_constantInteger( *new std::string( str.substr( 0, str.size()-1 ) ) );
 	delete &str;
Index: src/Parser/lex.ll
===================================================================
--- src/Parser/lex.ll	(revision 4203f71b5852a52f2a4817e35a8ec4100c1ac7f7)
+++ src/Parser/lex.ll	(revision 02153febd80045a0fdce301fb0f003053d5fa36c)
@@ -10,6 +10,6 @@
  * Created On       : Sat Sep 22 08:58:10 2001
  * Last Modified By : Peter A. Buhr
- * Last Modified On : Mon Mar 13 08:36:17 2017
- * Update Count     : 506
+ * Last Modified On : Thu May 18 09:03:49 2017
+ * Update Count     : 513
  */
 
@@ -77,5 +77,5 @@
 				// numeric constants, CFA: '_' in constant
 hex_quad {hex}("_"?{hex}){3}
-integer_suffix "_"?(([uU][lL]?)|([uU]("ll"|"LL")?)|([lL][uU]?)|("ll"|"LL")[uU]?)
+integer_suffix "_"?(([uU](("ll"|"LL"|[lL])[iI]|[iI]?("ll"|"LL"|[lL])?))|([iI](("ll"|"LL"|[lL])[uU]|[uU]?("ll"|"LL"|[lL])?))|(("ll"|"LL"|[lL])([iI][uU]|[uU]?[iI]?)))
 
 octal_digits ({octal})|({octal}({octal}|"_")*{octal})
@@ -91,11 +91,10 @@
 
 decimal_digits ({decimal})|({decimal}({decimal}|"_")*{decimal})
-real_decimal {decimal_digits}"."
-real_fraction "."{decimal_digits}
-real_constant {decimal_digits}?{real_fraction}
+real_decimal {decimal_digits}"."{exponent}?{floating_suffix}?
+real_fraction "."{decimal_digits}{exponent}?{floating_suffix}?
+real_constant {decimal_digits}{real_fraction}
 exponent "_"?[eE]"_"?[+-]?{decimal_digits}
-				// GCC: D (double), DL (long double) and iI (imaginary) suffixes
-floating_suffix "_"?([fFdDlL][iI]?|"DL"|[iI][lLfFdD]?)
-				//floating_suffix "_"?([fFdD]|[lL]|[D][L])|([iI][lLfFdD])|([lLfFdD][iI]))
+				// GCC: D (double) and iI (imaginary) suffixes, and DL (long double)
+floating_suffix "_"?([fFdDlL][iI]?|[iI][lLfFdD]?|"DL")
 floating_constant (({real_constant}{exponent}?)|({decimal_digits}{exponent})){floating_suffix}?
 
Index: src/tests/.expect/64/gmp.txt
===================================================================
--- src/tests/.expect/64/gmp.txt	(revision 02153febd80045a0fdce301fb0f003053d5fa36c)
+++ src/tests/.expect/64/gmp.txt	(revision 02153febd80045a0fdce301fb0f003053d5fa36c)
@@ -0,0 +1,272 @@
+constructors
+50000000000000000000 3 50000000000000000003
+x:50000000000000000000 y:3 z:50000000000000000003
+conversions
+y:97
+y:3
+y:-3
+y:4
+y:3
+y:3 b:3 si:3
+comparison
+1
+0
+0
+1
+0
+1
+arithmetic
+z:100000000000000000006
+z:50000000000000000000
+z:-3
+z:-450000000000000000000
+z:150000000000000000000
+z:150000000000000000000
+z:16666666666666666666
+x:16666666666666666666 y:2
+
+Fibonacci Numbers
+0 0
+1 1
+2 1
+3 2
+4 3
+5 5
+6 8
+7 13
+8 21
+9 34
+10 55
+11 89
+12 144
+13 233
+14 377
+15 610
+16 987
+17 1597
+18 2584
+19 4181
+20 6765
+21 10946
+22 17711
+23 28657
+24 46368
+25 75025
+26 121393
+27 196418
+28 317811
+29 514229
+30 832040
+31 1346269
+32 2178309
+33 3524578
+34 5702887
+35 9227465
+36 14930352
+37 24157817
+38 39088169
+39 63245986
+40 102334155
+41 165580141
+42 267914296
+43 433494437
+44 701408733
+45 1134903170
+46 1836311903
+47 2971215073
+48 4807526976
+49 7778742049
+50 12586269025
+51 20365011074
+52 32951280099
+53 53316291173
+54 86267571272
+55 139583862445
+56 225851433717
+57 365435296162
+58 591286729879
+59 956722026041
+60 1548008755920
+61 2504730781961
+62 4052739537881
+63 6557470319842
+64 10610209857723
+65 17167680177565
+66 27777890035288
+67 44945570212853
+68 72723460248141
+69 117669030460994
+70 190392490709135
+71 308061521170129
+72 498454011879264
+73 806515533049393
+74 1304969544928657
+75 2111485077978050
+76 3416454622906707
+77 5527939700884757
+78 8944394323791464
+79 14472334024676221
+80 23416728348467685
+81 37889062373143906
+82 61305790721611591
+83 99194853094755497
+84 160500643816367088
+85 259695496911122585
+86 420196140727489673
+87 679891637638612258
+88 1100087778366101931
+89 1779979416004714189
+90 2880067194370816120
+91 4660046610375530309
+92 7540113804746346429
+93 12200160415121876738
+94 19740274219868223167
+95 31940434634990099905
+96 51680708854858323072
+97 83621143489848422977
+98 135301852344706746049
+99 218922995834555169026
+100 354224848179261915075
+101 573147844013817084101
+102 927372692193078999176
+103 1500520536206896083277
+104 2427893228399975082453
+105 3928413764606871165730
+106 6356306993006846248183
+107 10284720757613717413913
+108 16641027750620563662096
+109 26925748508234281076009
+110 43566776258854844738105
+111 70492524767089125814114
+112 114059301025943970552219
+113 184551825793033096366333
+114 298611126818977066918552
+115 483162952612010163284885
+116 781774079430987230203437
+117 1264937032042997393488322
+118 2046711111473984623691759
+119 3311648143516982017180081
+120 5358359254990966640871840
+121 8670007398507948658051921
+122 14028366653498915298923761
+123 22698374052006863956975682
+124 36726740705505779255899443
+125 59425114757512643212875125
+126 96151855463018422468774568
+127 155576970220531065681649693
+128 251728825683549488150424261
+129 407305795904080553832073954
+130 659034621587630041982498215
+131 1066340417491710595814572169
+132 1725375039079340637797070384
+133 2791715456571051233611642553
+134 4517090495650391871408712937
+135 7308805952221443105020355490
+136 11825896447871834976429068427
+137 19134702400093278081449423917
+138 30960598847965113057878492344
+139 50095301248058391139327916261
+140 81055900096023504197206408605
+141 131151201344081895336534324866
+142 212207101440105399533740733471
+143 343358302784187294870275058337
+144 555565404224292694404015791808
+145 898923707008479989274290850145
+146 1454489111232772683678306641953
+147 2353412818241252672952597492098
+148 3807901929474025356630904134051
+149 6161314747715278029583501626149
+150 9969216677189303386214405760200
+151 16130531424904581415797907386349
+152 26099748102093884802012313146549
+153 42230279526998466217810220532898
+154 68330027629092351019822533679447
+155 110560307156090817237632754212345
+156 178890334785183168257455287891792
+157 289450641941273985495088042104137
+158 468340976726457153752543329995929
+159 757791618667731139247631372100066
+160 1226132595394188293000174702095995
+161 1983924214061919432247806074196061
+162 3210056809456107725247980776292056
+163 5193981023518027157495786850488117
+164 8404037832974134882743767626780173
+165 13598018856492162040239554477268290
+166 22002056689466296922983322104048463
+167 35600075545958458963222876581316753
+168 57602132235424755886206198685365216
+169 93202207781383214849429075266681969
+170 150804340016807970735635273952047185
+171 244006547798191185585064349218729154
+172 394810887814999156320699623170776339
+173 638817435613190341905763972389505493
+174 1033628323428189498226463595560281832
+175 1672445759041379840132227567949787325
+176 2706074082469569338358691163510069157
+177 4378519841510949178490918731459856482
+178 7084593923980518516849609894969925639
+179 11463113765491467695340528626429782121
+180 18547707689471986212190138521399707760
+181 30010821454963453907530667147829489881
+182 48558529144435440119720805669229197641
+183 78569350599398894027251472817058687522
+184 127127879743834334146972278486287885163
+185 205697230343233228174223751303346572685
+186 332825110087067562321196029789634457848
+187 538522340430300790495419781092981030533
+188 871347450517368352816615810882615488381
+189 1409869790947669143312035591975596518914
+190 2281217241465037496128651402858212007295
+191 3691087032412706639440686994833808526209
+192 5972304273877744135569338397692020533504
+193 9663391306290450775010025392525829059713
+194 15635695580168194910579363790217849593217
+195 25299086886458645685589389182743678652930
+196 40934782466626840596168752972961528246147
+197 66233869353085486281758142155705206899077
+198 107168651819712326877926895128666735145224
+199 173402521172797813159685037284371942044301
+200 280571172992510140037611932413038677189525
+
+Factorial Numbers
+0 1
+1 1
+2 2
+3 6
+4 24
+5 120
+6 720
+7 5040
+8 40320
+9 362880
+10 3628800
+11 39916800
+12 479001600
+13 6227020800
+14 87178291200
+15 1307674368000
+16 20922789888000
+17 355687428096000
+18 6402373705728000
+19 121645100408832000
+20 2432902008176640000
+21 51090942171709440000
+22 1124000727777607680000
+23 25852016738884976640000
+24 620448401733239439360000
+25 15511210043330985984000000
+26 403291461126605635584000000
+27 10888869450418352160768000000
+28 304888344611713860501504000000
+29 8841761993739701954543616000000
+30 265252859812191058636308480000000
+31 8222838654177922817725562880000000
+32 263130836933693530167218012160000000
+33 8683317618811886495518194401280000000
+34 295232799039604140847618609643520000000
+35 10333147966386144929666651337523200000000
+36 371993326789901217467999448150835200000000
+37 13763753091226345046315979581580902400000000
+38 523022617466601111760007224100074291200000000
+39 20397882081197443358640281739902897356800000000
+40 815915283247897734345611269596115894272000000000
Index: src/tests/.expect/complex.txt
===================================================================
--- src/tests/.expect/complex.txt	(revision 02153febd80045a0fdce301fb0f003053d5fa36c)
+++ src/tests/.expect/complex.txt	(revision 02153febd80045a0fdce301fb0f003053d5fa36c)
@@ -0,0 +1,4 @@
+x:3+2i y:4+5i z:7+7i
+x:3+2i y:4+5i z:7+7i
+x:2.1+1.3i y:3.2+4.5i z:5.3+5.8i
+x:2.1+1.3i y:3.2+4.5i z:5.3+5.8i
Index: c/tests/.expect/gmp.txt
===================================================================
--- src/tests/.expect/gmp.txt	(revision 4203f71b5852a52f2a4817e35a8ec4100c1ac7f7)
+++ 	(revision )
@@ -1,272 +1,0 @@
-constructors
-50000000000000000000 3 50000000000000000003
-x:50000000000000000000 y:3 z:50000000000000000003
-conversions
-y:97
-y:3
-y:-3
-y:4
-y:3
-y:3 b:3 si:3
-comparison
-1
-0
-0
-1
-0
-1
-arithmetic
-z:100000000000000000006
-z:50000000000000000000
-z:-3
-z:-450000000000000000000
-z:150000000000000000000
-z:150000000000000000000
-z:16666666666666666666
-x:16666666666666666666 y:2
-
-Fibonacci Numbers
-0 0
-1 1
-2 1
-3 2
-4 3
-5 5
-6 8
-7 13
-8 21
-9 34
-10 55
-11 89
-12 144
-13 233
-14 377
-15 610
-16 987
-17 1597
-18 2584
-19 4181
-20 6765
-21 10946
-22 17711
-23 28657
-24 46368
-25 75025
-26 121393
-27 196418
-28 317811
-29 514229
-30 832040
-31 1346269
-32 2178309
-33 3524578
-34 5702887
-35 9227465
-36 14930352
-37 24157817
-38 39088169
-39 63245986
-40 102334155
-41 165580141
-42 267914296
-43 433494437
-44 701408733
-45 1134903170
-46 1836311903
-47 2971215073
-48 4807526976
-49 7778742049
-50 12586269025
-51 20365011074
-52 32951280099
-53 53316291173
-54 86267571272
-55 139583862445
-56 225851433717
-57 365435296162
-58 591286729879
-59 956722026041
-60 1548008755920
-61 2504730781961
-62 4052739537881
-63 6557470319842
-64 10610209857723
-65 17167680177565
-66 27777890035288
-67 44945570212853
-68 72723460248141
-69 117669030460994
-70 190392490709135
-71 308061521170129
-72 498454011879264
-73 806515533049393
-74 1304969544928657
-75 2111485077978050
-76 3416454622906707
-77 5527939700884757
-78 8944394323791464
-79 14472334024676221
-80 23416728348467685
-81 37889062373143906
-82 61305790721611591
-83 99194853094755497
-84 160500643816367088
-85 259695496911122585
-86 420196140727489673
-87 679891637638612258
-88 1100087778366101931
-89 1779979416004714189
-90 2880067194370816120
-91 4660046610375530309
-92 7540113804746346429
-93 12200160415121876738
-94 19740274219868223167
-95 31940434634990099905
-96 51680708854858323072
-97 83621143489848422977
-98 135301852344706746049
-99 218922995834555169026
-100 354224848179261915075
-101 573147844013817084101
-102 927372692193078999176
-103 1500520536206896083277
-104 2427893228399975082453
-105 3928413764606871165730
-106 6356306993006846248183
-107 10284720757613717413913
-108 16641027750620563662096
-109 26925748508234281076009
-110 43566776258854844738105
-111 70492524767089125814114
-112 114059301025943970552219
-113 184551825793033096366333
-114 298611126818977066918552
-115 483162952612010163284885
-116 781774079430987230203437
-117 1264937032042997393488322
-118 2046711111473984623691759
-119 3311648143516982017180081
-120 5358359254990966640871840
-121 8670007398507948658051921
-122 14028366653498915298923761
-123 22698374052006863956975682
-124 36726740705505779255899443
-125 59425114757512643212875125
-126 96151855463018422468774568
-127 155576970220531065681649693
-128 251728825683549488150424261
-129 407305795904080553832073954
-130 659034621587630041982498215
-131 1066340417491710595814572169
-132 1725375039079340637797070384
-133 2791715456571051233611642553
-134 4517090495650391871408712937
-135 7308805952221443105020355490
-136 11825896447871834976429068427
-137 19134702400093278081449423917
-138 30960598847965113057878492344
-139 50095301248058391139327916261
-140 81055900096023504197206408605
-141 131151201344081895336534324866
-142 212207101440105399533740733471
-143 343358302784187294870275058337
-144 555565404224292694404015791808
-145 898923707008479989274290850145
-146 1454489111232772683678306641953
-147 2353412818241252672952597492098
-148 3807901929474025356630904134051
-149 6161314747715278029583501626149
-150 9969216677189303386214405760200
-151 16130531424904581415797907386349
-152 26099748102093884802012313146549
-153 42230279526998466217810220532898
-154 68330027629092351019822533679447
-155 110560307156090817237632754212345
-156 178890334785183168257455287891792
-157 289450641941273985495088042104137
-158 468340976726457153752543329995929
-159 757791618667731139247631372100066
-160 1226132595394188293000174702095995
-161 1983924214061919432247806074196061
-162 3210056809456107725247980776292056
-163 5193981023518027157495786850488117
-164 8404037832974134882743767626780173
-165 13598018856492162040239554477268290
-166 22002056689466296922983322104048463
-167 35600075545958458963222876581316753
-168 57602132235424755886206198685365216
-169 93202207781383214849429075266681969
-170 150804340016807970735635273952047185
-171 244006547798191185585064349218729154
-172 394810887814999156320699623170776339
-173 638817435613190341905763972389505493
-174 1033628323428189498226463595560281832
-175 1672445759041379840132227567949787325
-176 2706074082469569338358691163510069157
-177 4378519841510949178490918731459856482
-178 7084593923980518516849609894969925639
-179 11463113765491467695340528626429782121
-180 18547707689471986212190138521399707760
-181 30010821454963453907530667147829489881
-182 48558529144435440119720805669229197641
-183 78569350599398894027251472817058687522
-184 127127879743834334146972278486287885163
-185 205697230343233228174223751303346572685
-186 332825110087067562321196029789634457848
-187 538522340430300790495419781092981030533
-188 871347450517368352816615810882615488381
-189 1409869790947669143312035591975596518914
-190 2281217241465037496128651402858212007295
-191 3691087032412706639440686994833808526209
-192 5972304273877744135569338397692020533504
-193 9663391306290450775010025392525829059713
-194 15635695580168194910579363790217849593217
-195 25299086886458645685589389182743678652930
-196 40934782466626840596168752972961528246147
-197 66233869353085486281758142155705206899077
-198 107168651819712326877926895128666735145224
-199 173402521172797813159685037284371942044301
-200 280571172992510140037611932413038677189525
-
-Factorial Numbers
-0 1
-1 1
-2 2
-3 6
-4 24
-5 120
-6 720
-7 5040
-8 40320
-9 362880
-10 3628800
-11 39916800
-12 479001600
-13 6227020800
-14 87178291200
-15 1307674368000
-16 20922789888000
-17 355687428096000
-18 6402373705728000
-19 121645100408832000
-20 2432902008176640000
-21 51090942171709440000
-22 1124000727777607680000
-23 25852016738884976640000
-24 620448401733239439360000
-25 15511210043330985984000000
-26 403291461126605635584000000
-27 10888869450418352160768000000
-28 304888344611713860501504000000
-29 8841761993739701954543616000000
-30 265252859812191058636308480000000
-31 8222838654177922817725562880000000
-32 263130836933693530167218012160000000
-33 8683317618811886495518194401280000000
-34 295232799039604140847618609643520000000
-35 10333147966386144929666651337523200000000
-36 371993326789901217467999448150835200000000
-37 13763753091226345046315979581580902400000000
-38 523022617466601111760007224100074291200000000
-39 20397882081197443358640281739902897356800000000
-40 815915283247897734345611269596115894272000000000
Index: src/tests/complex.c
===================================================================
--- src/tests/complex.c	(revision 02153febd80045a0fdce301fb0f003053d5fa36c)
+++ src/tests/complex.c	(revision 02153febd80045a0fdce301fb0f003053d5fa36c)
@@ -0,0 +1,21 @@
+#include <stdio.h>
+#include <complex.h>
+#ifdef __CFA__
+#include <fstream>
+#endif // __CFA
+
+int main( void ) {
+    double _Complex x = 3 + 2i, y = 4 + 5i, z;
+    z = x + y;
+    printf( "x:%g+%gi y:%g+%gi z:%g+%gi\n", creal(x), cimag(x), creal(y), cimag(y), creal(z), cimag(z) );
+#ifdef __CFA__
+    sout | "x:" | x | "y:" | y | "z:" | z | endl;
+#endif // __CFA
+    x = 2.1 + 1.3i;
+    y = 3.2 + 4.5i;
+    z = x + y;
+    printf( "x:%g+%gi y:%g+%gi z:%g+%gi\n", creal(x), cimag(x), creal(y), cimag(y), creal(z), cimag(z) );
+#ifdef __CFA__
+    sout | "x:" | x | "y:" | y | "z:" | z | endl;
+#endif // __CFA
+}
