Index: doc/papers/general/Makefile
===================================================================
--- doc/papers/general/Makefile	(revision 387c9a1380c2073ad82b477bb8b65388dc6393cc)
+++ doc/papers/general/Makefile	(revision 3d60c08ac51fee59e5e460399d8f60bfa15e20c6)
@@ -44,4 +44,7 @@
 clean :
 	@rm -frv ${DOCUMENT} ${BASE}.ps WileyNJD-AMA.bst ${BASE}.out.ps ${Build}
+
+Paper.zip :
+	zip -x general/.gitignore -x general/"*AMA*" -x general/Paper.out.ps -x general/Paper.tex.plain -x general/evaluation.zip -x general/mail -x general/response -x general/test.c -x general/evaluation.zip -x general/Paper.tex.plain -x general/Paper.ps -x general/Paper.pdf -x general/"*build*" -x general/evaluation/.gitignore -x general/evaluation/timing.xlsx -r Paper.zip general
 
 evaluation.zip :
Index: doc/papers/general/Paper.tex
===================================================================
--- doc/papers/general/Paper.tex	(revision 387c9a1380c2073ad82b477bb8b65388dc6393cc)
+++ doc/papers/general/Paper.tex	(revision 3d60c08ac51fee59e5e460399d8f60bfa15e20c6)
@@ -60,5 +60,5 @@
 \renewcommand{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.075ex}}}
 
-\renewcommand*{\thefootnote}{\alph{footnote}} % hack because fnsymbol does not work
+\renewcommand*{\thefootnote}{\Alph{footnote}} % hack because fnsymbol does not work
 %\renewcommand*{\thefootnote}{\fnsymbol{footnote}}
 
@@ -249,5 +249,5 @@
 All languages features discussed in this paper are working, except some advanced exception-handling features.
 Not discussed in this paper are the integrated concurrency-constructs and user-level threading-library~\cite{Delisle18}.
-\CFA is an \emph{open-source} project implemented as an source-to-source translator from \CFA to the gcc-dialect of C~\cite{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by gcc, meeting goals (1)--(3).
+\CFA is an \emph{open-source} project implemented as a source-to-source translator from \CFA to the gcc-dialect of C~\cite{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by gcc, meeting goals (1)--(3).
 Ultimately, a compiler is necessary for advanced features and optimal performance.
 % @plg2[9]% cd cfa-cc/src; cloc ArgTweak CodeGen CodeTools Common Concurrency ControlStruct Designators GenPoly InitTweak MakeLibCfa.cc MakeLibCfa.h Parser ResolvExpr SymTab SynTree Tuples driver prelude main.cc 
@@ -323,5 +323,5 @@
 There are only two hard things in Computer Science: cache invalidation and \emph{naming things} -- Phil Karlton
 \end{quote}
-\vspace{-10pt}
+\vspace{-9pt}
 C already has a limited form of ad-hoc polymorphism in the form of its basic arithmetic operators, which apply to a variety of different types using identical syntax. 
 \CFA extends the built-in operator overloading by allowing users to define overloads for any function, not just operators, and even any variable;
@@ -438,5 +438,5 @@
 Hence, programmers can easily form local environments, adding and modifying appropriate functions, to maximize reuse of other existing functions and types.
 
-To reducing duplication, it is possible to distribute a group of @forall@ (and storage-class qualifiers) over functions/types, so each block declaration is prefixed by the group (see example in Appendix~\ref{s:CforallStack}).
+To reduce duplication, it is possible to distribute a group of @forall@ (and storage-class qualifiers) over functions/types, so each block declaration is prefixed by the group (see example in Appendix~\ref{s:CforallStack}).
 \begin{cfa}
 forall( otype `T` ) {							$\C{// distribution block, add forall qualifier to declarations}$
@@ -480,5 +480,6 @@
 \end{cquote}
 
-In fact, the set of @summable@ trait operators is incomplete, as it is missing assignment for type @T@, but @otype@ is syntactic sugar for the following implicit trait:
+Note, the @sumable@ trait does not include a copy constructor needed for the right side of @?+=?@ and return;
+it is provided by @otype@, which is syntactic sugar for the following trait:
 \begin{cfa}
 trait otype( dtype T | sized(T) ) {  // sized is a pseudo-trait for types with known size and alignment
@@ -498,5 +499,5 @@
 Instead, each polymorphic function (or generic type) defines the structural type needed for its execution (polymorphic type-key), and this key is fulfilled at each call site from the lexical environment, which is similar to Go~\cite{Go} interfaces.
 Hence, new lexical scopes and nested functions are used extensively to create local subtypes, as in the @qsort@ example, without having to manage a nominal-inheritance hierarchy.
-(Nominal inheritance can be approximated with traits using marker variables or functions, as is done in Go.)
+% (Nominal inheritance can be approximated with traits using marker variables or functions, as is done in Go.)
 
 % Nominal inheritance can be simulated with traits using marker variables or functions:
@@ -525,5 +526,4 @@
 
 
-\vspace*{-2pt}
 \section{Generic Types}
 
@@ -571,5 +571,6 @@
 Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters.
 A \newterm{dtype-static} type has polymorphic parameters but is still concrete.
-Polymorphic pointers are an example of dtype-static types, \eg @forall(dtype T) T *@ is a polymorphic type, but for any @T@, @T *@  is a fixed-sized pointer, and therefore, can be represented by a @void *@ in code generation.
+Polymorphic pointers are an example of dtype-static types;
+given some type variable @T@, @T@ is a polymorphic type, as is @T *@, but @T *@ has a fixed size and can therefore be represented by @void *@ in code generation.
 
 \CFA generic types also allow checked argument-constraints.
@@ -955,13 +956,13 @@
 }
 \end{cfa}
-One more step permits the summation of any summable type with all arguments of the same type:
-\begin{cfa}
-trait summable( otype T ) {
+One more step permits the summation of any sumable type with all arguments of the same type:
+\begin{cfa}
+trait sumable( otype T ) {
 	T ?+?( T, T );
 };
-forall( otype R | summable( R ) ) R sum( R x, R y ) {
+forall( otype R | sumable( R ) ) R sum( R x, R y ) {
 	return x + y;
 }
-forall( otype R, ttype Params | summable(R) | { R sum(R, Params); } ) R sum(R x, R y, Params rest) {
+forall( otype R, ttype Params | sumable(R) | { R sum(R, Params); } ) R sum(R x, R y, Params rest) {
 	return sum( x + y, rest );
 }
@@ -1108,6 +1109,6 @@
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l|@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
+\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
 \begin{cfa}
 case 2, 10, 34, 42:
@@ -1124,5 +1125,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
 \begin{cfa}
 case 2~42:
@@ -1178,5 +1179,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
+\multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
 \begin{cfa}
 `choose` ( day ) {
@@ -1224,5 +1225,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{non-terminator}}	& \multicolumn{1}{c}{\textbf{target label}}	\\
+\multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{non-terminator}}	& \multicolumn{1}{c@{}}{\textbf{target label}}	\\
 \begin{cfa}
 choose ( ... ) {
@@ -1268,5 +1269,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{\hspace{\parindentlnth}}l|@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{@{\hspace{\parindentlnth}}c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{@{\hspace{\parindentlnth}}c}{\textbf{C}}	\\
+\multicolumn{1}{@{\hspace{\parindentlnth}}c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{@{\hspace{\parindentlnth}}c@{}}{\textbf{C}}	\\
 \begin{cfa}
 `LC:` {
@@ -1364,5 +1365,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l|@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{Resumption}}	& \multicolumn{1}{c}{\textbf{Termination}}	\\
+\multicolumn{1}{@{}c|@{\hspace{\parindentlnth}}}{\textbf{Resumption}}	& \multicolumn{1}{c@{}}{\textbf{Termination}}	\\
 \begin{cfa}
 `exception R { int fix; };`
@@ -1632,5 +1633,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
 \begin{cfa}
 `[5] *` int x1;
@@ -1660,5 +1661,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
 \begin{cfa}
 `*` int x, y;
@@ -1681,5 +1682,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}	\\
 \begin{cfa}
 [ 5 ] int z;
@@ -1723,5 +1724,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{C}}	\\
 \begin{cfa}
 extern const * const int x;
@@ -1748,5 +1749,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
 \begin{cfa}
 y = (* int)x;
@@ -1776,5 +1777,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
 \begin{cfa}
 [double] foo(), foo( int ), foo( double ) {...}
@@ -1794,5 +1795,5 @@
 * [ * int ] ( int y ) gp;		$\C{// pointer to function returning pointer to int with int parameter}$
 * [ ] ( int, char ) hp;			$\C{// pointer to function returning no result with int and char parameters}$
-* [ * int, int ] ( int ) jp;	$\C{// pointer to function returning pointer to int and int with int parameter}$
+* [ * int, int ] ( int ) jp;	$\C{// pointer to function returning pointer to int and int with int parameter}\CRT$
 \end{cfa}
 Note, the name of the function pointer is specified last, as for other variable declarations.
@@ -1993,8 +1994,8 @@
 The symbol \lstinline+^+ is used for the destructor name because it was the last binary operator that could be used in a unary context.}.
 The name @{}@ comes from the syntax for the initializer: @struct S { int i, j; } s = `{` 2, 3 `}`@.
-Like other \CFA operators, these names represent the syntax used to call the constructor or destructor, \eg @?{}(x, ...)@ or @^{}(x, ...)@.
+Like other \CFA operators, these names represent the syntax used to explicitly call the constructor or destructor, \eg @s{...}@ or @^s{...}@.
 The constructor and destructor have return type @void@, and the first parameter is a reference to the object type to be constructed or destructed.
 While the first parameter is informally called the @this@ parameter, as in object-oriented languages, any variable name may be used.
-Both constructors and destructors allow additional parametes after the @this@ parameter for specifying values for initialization/de-initialization\footnote{
+Both constructors and destructors allow additional parameters after the @this@ parameter for specifying values for initialization/de-initialization\footnote{
 Destruction parameters are useful for specifying storage-management actions, such as de-initialize but not deallocate.}.
 \begin{cfa}
@@ -2003,6 +2004,6 @@
 void ^?{}( VLA & vla ) with ( vla ) { free( data ); } $\C{// destructor}$
 {
-	VLA x;									$\C{// implicit:  ?\{\}( x );}$
-} 											$\C{// implicit:  ?\^{}\{\}( x );}$
+	VLA x;									$\C{// implicit:\ \ x\{\};}$
+} 											$\C{// implicit:\ \textasciicircum{}x\{\};}$
 \end{cfa}
 @VLA@ is a \newterm{managed type}\footnote{
@@ -2029,11 +2030,11 @@
 appropriate care is taken to not recursively call the copy constructor when initializing the second parameter.
 
-\CFA constructors may be explicitly call, like Java, and destructors may be explicitly called, like \CC.
+\CFA constructors may be explicitly called, like Java, and destructors may be explicitly called, like \CC.
 Explicit calls to constructors double as a \CC-style \emph{placement syntax}, useful for construction of member fields in user-defined constructors and reuse of existing storage allocations.
-While existing call syntax works for explicit calls to constructors and destructors, \CFA also provides a more concise \newterm{operator syntax} for both:
+Like the other operators in \CFA, there is a concise syntax for constructor/destructor function calls:
 \begin{cfa}
 {
 	VLA  x,            y = { 20, 0x01 },     z = y;	$\C{// z points to y}$
-	//      ?{}( x );   ?{}( y, 20, 0x01 );   ?{}( z, y ); 
+	//    x{};         y{ 20, 0x01 };          z{ z, y }; 
 	^x{};									$\C{// deallocate x}$
 	x{};									$\C{// reallocate x}$
@@ -2042,5 +2043,5 @@
 	y{ x };									$\C{// reallocate y, points to x}$
 	x{};									$\C{// reallocate x, not pointing to y}$
-	// ^?{}(z);  ^?{}(y);  ^?{}(x);
+	//  ^z{};  ^y{};  ^x{};
 }
 \end{cfa}
@@ -2063,5 +2064,5 @@
 In these cases, \CFA provides the initialization syntax \lstinline|S x `@=` {}|, and the object becomes unmanaged, so implicit constructor and destructor calls are not generated. 
 Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg \lstinline|VLA a @= { 0, 0x0 }|, with the usual C initialization semantics.
-The same syntax can be used in a compound literal, \eg \lstinline|a = VLA`@`{ 0, 0x0 }|, to create a C-style literal.
+The same syntax can be used in a compound literal, \eg \lstinline|a = (VLA)`@`{ 0, 0x0 }|, to create a C-style literal.
 The point of \lstinline|@=| is to provide a migration path from legacy C code to \CFA, by providing a mechanism to incrementally convert to implicit initialization.
 
@@ -2119,5 +2120,5 @@
 
 In C, @0@ has the special property that it is the only ``false'' value;
-from the standard, any value that compares equal to @0@ is false, while any value that compares unequal to @0@ is true. 
+by the standard, any value that compares equal to @0@ is false, while any value that compares unequal to @0@ is true. 
 As such, an expression @x@ in any boolean context (such as the condition of an @if@ or @while@ statement, or the arguments to @&&@, @||@, or @?:@\,) can be rewritten as @x != 0@ without changing its semantics.
 Operator overloading in \CFA provides a natural means to implement this truth-value comparison for arbitrary types, but the C type system is not precise enough to distinguish an equality comparison with @0@ from an equality comparison with an arbitrary integer or pointer. 
@@ -2154,5 +2155,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{postfix function}}	& \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{constant}}	& \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{variable/expression}}	& \multicolumn{1}{c}{\textbf{postfix pointer}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{postfix function}}	& \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{constant}}	& \multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{variable/expression}}	& \multicolumn{1}{c@{}}{\textbf{postfix pointer}}	\\
 \begin{cfa}
 int |?`h|( int s );
@@ -2199,6 +2200,6 @@
 \lstset{language=CFA,moredelim=**[is][\color{red}]{|}{|},deletedelim=**[is][]{`}{`}}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{\CC}}	\\
+\begin{tabular}{@{}l@{\hspace{1.25\parindentlnth}}l@{}}
+\multicolumn{1}{@{}c@{\hspace{1.25\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{\CC}}	\\
 \begin{cfa}
 struct W {
@@ -2274,5 +2275,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}	& \multicolumn{1}{c}{\textbf{Usage}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}	& \multicolumn{1}{c@{}}{\textbf{Usage}}	\\
 \begin{cfa}
 const short int `MIN` = -32768;
@@ -2293,5 +2294,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
+\multicolumn{1}{@{}c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
 \begin{cfa}
 MIN
@@ -2319,5 +2320,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}	& \multicolumn{1}{c}{\textbf{Usage}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}	& \multicolumn{1}{c@{}}{\textbf{Usage}}	\\
 \begin{cfa}
 float `log`( float x );
@@ -2338,5 +2339,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
 \begin{cfa}
 log
@@ -2366,5 +2367,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}	& \multicolumn{1}{c}{\textbf{Usage}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{Definition}}	& \multicolumn{1}{c@{}}{\textbf{Usage}}	\\
 \begin{cfa}
 unsigned int `abs`( int );
@@ -2385,5 +2386,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
 \begin{cfa}
 abs
@@ -2408,5 +2409,5 @@
 an allocation with a specified character.
 \item[resize]
-an existing allocation to decreased or increased its size.
+an existing allocation to decrease or increase its 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.
@@ -2447,6 +2448,5 @@
 \begin{figure}
 \centering
-\begin{cquote}
-\begin{cfa}[aboveskip=0pt]
+\begin{cfa}[aboveskip=0pt,xleftmargin=0pt]
 size_t  dim = 10;							$\C{// array dimension}$
 char fill = '\xff';							$\C{// initialization fill value}$
@@ -2454,7 +2454,7 @@
 \end{cfa}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{C}}	\\
-\begin{cfa}
+\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
+\multicolumn{1}{@{}c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
+\begin{cfa}[xleftmargin=-10pt]
 ip = alloc();
 ip = alloc( fill );
@@ -2471,19 +2471,18 @@
 &
 \begin{cfa}
-ip = (int *)malloc( sizeof( int ) );
-ip = (int *)malloc( sizeof( int ) ); memset( ip, fill, sizeof( int ) );
-ip = (int *)malloc( dim * sizeof( int ) );
-ip = (int *)malloc( sizeof( int ) ); memset( ip, fill, dim * sizeof( int ) );
-ip = (int *)realloc( ip, 2 * dim * sizeof( int ) );
-ip = (int *)realloc( ip, 4 * dim * sizeof( int ) );
-			memset( ip, fill, 4 * dim * sizeof( int ) );
-ip = memalign( 16, sizeof( int ) );
-ip = memalign( 16, sizeof( int ) ); memset( ip, fill, sizeof( int ) );
-ip = memalign( 16, dim * sizeof( int ) );
-ip = memalign( 16, dim * sizeof( int ) ); memset( ip, fill, dim * sizeof( int ) );
-\end{cfa}
-\end{tabular}
-\lstMakeShortInline@%
-\end{cquote}
+ip = (int *)malloc( sizeof(int) );
+ip = (int *)malloc( sizeof(int) ); memset( ip, fill, sizeof(int) );
+ip = (int *)malloc( dim * sizeof(int) );
+ip = (int *)malloc( sizeof(int) ); memset( ip, fill, dim * sizeof(int) );
+ip = (int *)realloc( ip, 2 * dim * sizeof(int) );
+ip = (int *)realloc( ip, 4 * dim * sizeof(int) ); memset( ip, fill, 4 * dim * sizeof(int));
+
+ip = memalign( 16, sizeof(int) );
+ip = memalign( 16, sizeof(int) ); memset( ip, fill, sizeof(int) );
+ip = memalign( 16, dim * sizeof(int) );
+ip = memalign( 16, dim * sizeof(int) ); memset( ip, fill, dim * sizeof(int) );
+\end{cfa}
+\end{tabular}
+\lstMakeShortInline@%
 \caption{\CFA versus C Storage-Allocation}
 \label{f:StorageAllocation}
@@ -2498,5 +2497,5 @@
 S * as = anew( dim, 2, 3 );					$\C{// each array element initialized to 2, 3}$
 \end{cfa}
-Note, \CC can only initialization array elements via the default constructor.
+Note, \CC can only initialize array elements via the default constructor.
 
 Finally, the \CFA memory-allocator has \newterm{sticky properties} for dynamic storage: fill and alignment are remembered with an object's storage in the heap.
@@ -2515,5 +2514,5 @@
 \lstDeleteShortInline@%
 \begin{tabular}{@{}l@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c}{\textbf{\CC}}	\\
+\multicolumn{1}{@{}c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{\CC}}	\\
 \begin{cfa}
 int x = 1, y = 2, z = 3;
@@ -2604,6 +2603,6 @@
 \centering
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{2\parindentlnth}}@{\hspace{2\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{2\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{@{\hspace{2\parindentlnth}}c}{\textbf{C}}	\\
+\begin{tabular}{@{}l@{\hspace{3\parindentlnth}}l@{}}
+\multicolumn{1}{@{}c@{\hspace{3\parindentlnth}}}{\textbf{\CFA}}	& \multicolumn{1}{c@{}}{\textbf{C}}	\\
 \begin{cfa}
 #include <gmp>
@@ -2638,5 +2637,5 @@
 
 
-\section{Polymorphic Evaluation}
+\section{Polymorphism Evaluation}
 \label{sec:eval}
 
@@ -2727,10 +2726,10 @@
 Line-count is a fairly rough measure of code complexity;
 another important factor is how much type information the programmer must specify manually, especially where that information is not compiler-checked.
-Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs, and is much less common in \CFA than C, with its manually specified function pointer arguments and format codes, or \CCV, with its extensive use of untype-checked downcasts, \eg @object@ to @integer@ when popping a stack.
+Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs, and is much less common in \CFA than C, with its manually specified function pointer arguments and format codes, or \CCV, with its extensive use of un-type-checked downcasts, \eg @object@ to @integer@ when popping a stack.
 To quantify this manual typing, the ``redundant type annotations'' line in Table~\ref{tab:eval} counts the number of lines on which the type of a known variable is respecified, either as a format specifier, explicit downcast, type-specific function, or by name in a @sizeof@, struct literal, or @new@ expression.
 The \CC benchmark uses two redundant type annotations to create a new stack nodes, while the C and \CCV benchmarks have several such annotations spread throughout their code.
 The \CFA benchmark is able to eliminate all redundant type annotations through use of the polymorphic @alloc@ function discussed in Section~\ref{sec:libraries}.
 
-We conjecture these results scale across most generic data-types as the underlying polymorphic implement is constant.
+We conjecture these results scale across most generic data-types as the underlying polymorphism implement is constant.
 
 
Index: doc/papers/general/response
===================================================================
--- doc/papers/general/response	(revision 387c9a1380c2073ad82b477bb8b65388dc6393cc)
+++ doc/papers/general/response	(revision 3d60c08ac51fee59e5e460399d8f60bfa15e20c6)
@@ -61,85 +61,92 @@
 judithbishop@outlook.com
 
+
+We have attempted to response to all the issues raised by the Editor and referee's comments. For two
+of the issues, we have "pushed back", with an explanation. Specifically, moving the related work
+forward, and moving text from Section 9 into the captions of Table2 and Figure 10.  Our reasons for
+not making these changes are address below. Finally, as pointed out below, there are a couple of
+issues with the Wiley LaTeX macros that we worked around as best as possible.
+
+   The paper is long by SPE standards (33 pages). We have a maximum of 40 pages. Please do not
+   extend the paper beyond 35 pages. If necessary, find ways to cut the examples or text. If you
+   have an accompanying website for the system where some examples are stored, please mention it.
+
+The paper is 35 pages using the supplied Wiley LaTeX macros.
+
+
 Referee(s)' Comments to Author:
 
 Reviewing: 1
 
-   Most of the content in Section 10 RELATED WORK appears to belong to Section
-   1 INTRODUCTION as a Subsection or as a new Section after Section 1. (Please
-   also see #4.1 below.) Remaining discussion that cannot be moved earlier can
-   become a DISCUSSION Section or a Subsection within the last Section of the
-   paper.
-
-Sometimes it is appropriate to put related work at the start of a paper and
-sometimes at the end. For this paper, it seems appropriate to put the related
-work at the end of the paper. The purpose of the related work in this paper is
-two fold: to introduce prior work and to contrast it with Cforall.  Only at the
-end of the paper does the reader have sufficient knowledge about Cforall to
-make detailed contrasts with other programming languages possible. If the
-related work is moved to the end of the introduction, the reader knows nothing
-about Cforall so talking about other programming languages in isolation makes
-little sense, especially non-C-related languages, like Java, Go, Rust,
-Haskell. We see no easy way to separate the related work into a general
-discussion at the start and a specific discussion at the end. We explicitly
-attempt to deal with the reader's anticipation at the end of the introduction:
-
- Finally, it is impossible to describe a programming language without usages
- before definitions.  Therefore, syntax and semantics appear before
- explanations; hence, patience is necessary until details are presented.
-
-
-   2. Presentation
-
-   2.1 More information should be moved from the text and added to Figure 10 and
-   Table 2 so that readers can understand the comparison quickly. Imagine a reader
-   read the summary and jump directly to these two display elements. Questions
-   would be raised about the binary size and pop pair result of Cforall and it
-   would take time to find answers in the text.
-
-This suggestion is an alternative writing style. The experiment is complex
-enough that it is unlikely a reader could jump to the table/graph and
-understand the experiment without putting a substantive amount of the text from
-Section 9 into the table and figure, which the reader then has to read anyway.
-In fact, we prefer a writing style where the reader does not have to look at
-the table/figure to understand the experiment and the results, i.e., the
-table/figure are only there to complement the discussion.
-
-   2.2 The pronunciation of ("C-for-all") should be provided in the summary
-   (page 1 line 22) so that people not having an access to the full-text can
-   see it.
+   Most of the content in Section 10 RELATED WORK appears to belong to Section 1 INTRODUCTION as a
+   Subsection or as a new Section after Section 1. (Please also see #4.1 below.) Remaining
+   discussion that cannot be moved earlier can become a DISCUSSION Section or a Subsection within
+   the last Section of the paper.
+
+Sometimes it is appropriate to put related work at the start of a paper and sometimes at the
+end. For this paper, it seems appropriate to put the related work at the end of the paper. The
+purpose of the related work in this paper is two fold: to introduce prior work and to contrast it
+with Cforall.  Only at the end of the paper does the reader have sufficient knowledge about Cforall
+to make detailed contrasts with other programming languages possible. If the related work is moved
+to the end of the introduction, the reader knows nothing about Cforall so talking about other
+programming languages in isolation makes little sense, especially non-C-related languages, like
+Java, Go, Rust, Haskell. We see no easy way to separate the related work into a general discussion
+at the start and a specific discussion at the end. We explicitly attempt to deal with the reader's
+anticipation at the end of the introduction:
+
+ Finally, it is impossible to describe a programming language without usages before definitions.
+ Therefore, syntax and semantics appear before explanations; hence, patience is necessary until
+ details are presented.
+
+
+   2.1 More information should be moved from the text and added to Figure 10 and Table 2 so that
+   readers can understand the comparison quickly. Imagine a reader read the summary and jump
+   directly to these two display elements. Questions would be raised about the binary size and pop
+   pair result of Cforall and it would take time to find answers in the text.
+
+This suggestion is an alternative writing style. The experiment is complex enough that it is
+unlikely a reader could jump to the table/graph and understand the experiment without putting a
+substantive amount of the text from Section 9 into the table and figure, which the reader then has
+to read anyway.  In fact, we prefer a writing style where the reader does not have to look at the
+table/figure to understand the experiment and the results, i.e., the table/figure are only there to
+complement the discussion.
+
+
+   2.2 The pronunciation of ("C-for-all") should be provided in the summary (page 1 line 22) so that
+   people not having an access to the full-text can see it.
 
 Done.
 
-   2.3 Error comment in the code should be written with the same capitalization
-   and it will be helpful if you say specifically compilation error or runtime
-   error. (Please see attached annotated manuscript.)
-
-Fixed. All errors in the paper are compilation errors because they are related
-to the type system.
-
-   2.4 It is possible to provide a bit more information in Appendix A e.g. how
-   many lines/bytes of code and some details about software/hardware can be
-   added/moved here. The aim is to provide sufficient information for readers
-   to reproduce the results and to appreciate the context of the comparison.
-
-Table 2 indicates the source-code size in lines of code. The third paragraph of
-Section 9 gives precise details of the software/hardware used in the
-experiments.
+
+   2.3 Error comment in the code should be written with the same capitalization and it will be
+   helpful if you say specifically compilation error or runtime error. (Please see attached
+   annotated manuscript.)
+
+Fixed. All errors in the paper are compilation errors because they are related to the type system.
+
+
+   2.4 It is possible to provide a bit more information in Appendix A e.g. how many lines/bytes of
+   code and some details about software/hardware can be added/moved here. The aim is to provide
+   sufficient information for readers to reproduce the results and to appreciate the context of the
+   comparison.
+
+Table 2 indicates the source-code size in lines of code. The third paragraph of Section 9 gives
+precise details of the software/hardware used in the experiments.
 
    3. Practical information about the work
 
-   There are three separate pieces of information on pages 2 ("All features
-   discussed in this paper are working, unless otherwise stated as under
-   construction."),
+   There are three separate pieces of information on pages 2 ("All features discussed in this paper
+   are working, unless otherwise stated as under construction."),
 
 This sentence is replace with:
 
- All languages features discussed in this paper are working, except some
- advanced exception-handling features.
+ All languages features discussed in this paper are working, except some advanced exception-handling
+ features.
 
 and Section 5.4 Exception Handling states:
 
- The following framework for Cforall exception handling is in place, excluding
- some runtime type-information and virtual functions.
+ The following framework for Cforall exception handling is in place, excluding some runtime
+ type-information and virtual functions.
+
 
    page 4 ("Under construction is a mechanism to distribute...")
@@ -147,55 +154,52 @@
 The feature on page 4 is now complete.
 
+
    and page 33 ("There is ongoing work on a wide range ... ")
 
 This sentence is replace to indicate the ongoing work is future work.
 
- While all examples in the paper compile and run, a public beta-release of
- Cforall will take 6-8 months to reduce compilation time, provide better
- debugging, and add a few more libraries.  There is also new work on a number
- of Cforall features, including arrays with size, runtime type-information,
- virtual functions, user-defined conversions, and modules.
-
-   My recommendation is to move them to an appendix so that the length is
-   preserved.
-
-There is nothing to move into an appendix, except 3 sentences. We do not intend
-to discuss these items in this paper.
-
-   3.1 Any under construction work (only small part of page 4) should not be
-   mingled into the main part of the manuscript.
+ While all examples in the paper compile and run, a public beta-release of Cforall will take 6-8
+ months to reduce compilation time, provide better debugging, and add a few more libraries.  There
+ is also new work on a number of Cforall features, including arrays with size, runtime
+ type-information, virtual functions, user-defined conversions, and modules.
+
+
+   My recommendation is to move them to an appendix so that the length is preserved.
+
+There is nothing to move into an appendix, except 3 sentences. We do not intend to discuss these
+items in this paper.
+
+
+   3.1 Any under construction work (only small part of page 4) should not be mingled into the main
+   part of the manuscript.
 
 See above.
 
-   3.2 Instructions on how to access/use the working functionality of Cforall
-   should be given.
-
-We will indicate release of Cforall in a public location, when we believe the
-code base is acceptable. In the interim, we have made public all the
-experimental code from section 9, and there is a reference in the paper to
-access this code. We can make a private beta-copy of Cforall available to the
-SP&E editor for distribution to the referees so they can verify our claims.
-
-   3.3 Planned work should be given a specific time of completion/release not
-   just "8-12 months".
-
-Software development is not rigorous engineering discipline. Given our small
-research development-team and the size of the project, we cannot give a
-specific time for completion of anything associated with the project. Having
-said that, we have reduced our expected time for Cforall release to 6-8 months
-as work is progressing well.
-
-
-   4. Citations
-
-   4.1 The impression after reading Section 1 INTRODUCTION is that the
-   referencing is poor. It is not until Section 10 RELATED WORK where majority
-   of the prior literature are discussed. Please consider moving the content
-   and improve citations - at least cite all main variations of C languages.
+
+   3.2 Instructions on how to access/use the working functionality of Cforall should be given.
+
+We will indicate release of Cforall in a public location, when we believe the code base is
+acceptable. In the interim, we have made public all the experimental code from section 9, and there
+is a reference in the paper to access this code. We can make a private beta-copy of Cforall
+available to the SP&E editor for distribution to the referees so they can verify our claims.
+
+   3.3 Planned work should be given a specific time of completion/release not just "8-12 months".
+
+Software development is not a rigorous engineering discipline. Given our small research
+development-team and the size of the project, we cannot give a specific time for completion of
+anything associated with the project. Having said that, we have reduced our expected time for
+Cforall release to 6-8 months as work is progressing well.
+
+
+   4.1 The impression after reading Section 1 INTRODUCTION is that the referencing is poor. It is
+   not until Section 10 RELATED WORK where majority of the prior literature are discussed. Please
+   consider moving the content and improve citations - at least cite all main variations of C
+   languages.
 
 See point 1.
 
-   4.2 I also would like to see citations at these specific places: Page 2
-   after Phil Karlton, page 22 after const hell problem.
+
+   4.2 I also would like to see citations at these specific places: Page 2 after Phil Karlton, page
+   22 after const hell problem.
 
 The Phil-Karlton quote is an urban legend without a specific academic citation:
@@ -205,16 +209,19 @@
 The term "const hell" is replaced with "const poisoning" with a citation.
 
-   5.1 Footnotes and citations will need to have different schemes - number and
-   perhaps letter.
-
-The latex macros from Wiley generate those symbols. I assume during
-copy-editing the format is changed to suit the journal format.
-
-   5.2 Many references are not properly formatted e.g. date is incomplete,
-   extra/missing white spaces, extra dots, use of page number or section number
-   as part of superscript ref number. Please refer to attached document.
-
-Agreed. The bibtex BST macros are at fault. I have fixed some issues but I
-cannot fix them all as my BST macro-knowledge is limited.
+
+   5.1 Footnotes and citations will need to have different schemes - number and perhaps letter.
+
+Switched to letters. SP&E uses symbol footnotes but this macros fails with their macros:
+
+ \renewcommand*{\thefootnote}{\fnsymbol{footnote}}
+
+
+   5.2 Many references are not properly formatted e.g. date is incomplete, extra/missing white
+   spaces, extra dots, use of page number or section number as part of superscript ref
+   number. Please refer to attached document.
+
+Agreed. The bibtex BST macros are at fault. I have fixed some issues but I cannot fix them all as my
+BST macro-knowledge is limited.
+
 
    5.3 Typos:
@@ -233,10 +240,10 @@
 
    6. Conflict of interest
-   I see that the work is partially supported by Huawei. Perhaps statement
-   about any presence or absence of conflicts of interest should be explicitly
-   added. Please get a clear direction on this from the editor of the journal.
-
-The paper now states the project is open-source, hence there is no conflict of
-interest with the funding received from Huawei.
+   I see that the work is partially supported by Huawei. Perhaps statement about any presence or
+   absence of conflicts of interest should be explicitly added. Please get a clear direction on this
+   from the editor of the journal.
+
+The paper now states the project is open-source, hence there is no conflict of interest with the
+funding received from Huawei.
 
 
@@ -245,77 +252,76 @@
 Comments to the Author
 
-   Overloading requires the compiler to mangle a function's signature into its
-   name in the object file.  I'm pretty sure that this will complicate the
-   build process of mixed Cforall/C projects.
-
-There is no complexity with building Cforall/C programs, and there is an
-existence proof because C++ has name mangling for overloading and has no problem
-interacting with C.
-
-   I found the evaluation underwhelming.  There were only ~200 LoC ported from
-   C to Cforall.  This is too less to encounter potential caveats Cforall's
-   type system might impose.
-
-
-
-   Also, how is the compiler implemented?  I guess, Cforall is a
-   source-to-source compiler (from Cforall to C).  But this is left in the
-   dark.  What features are actually implemented?
-
-The following paragraph has been added to the introduction to address this
-comment:
-
- All languages features discussed in this paper are working, except some
- advanced exception-handling features.  Not discussed in this paper are the
- integrated concurrency-constructs and user-level
- threading-library~\cite{Delisle18}.  Cforall is an open-source project
- implemented as an source-to-source translator from Cforall to the gcc-dialect
- of C~\cite{GCCExtensions}, allowing it to leverage the portability and code
- optimizations provided by gcc, meeting goals (1)--(3).  Ultimately, a compiler
- is necessary for advanced features and optimal performance.  The Cforall
- translator is 200+ files and 46,000+ lines of code written in C/C++.  Starting
- with a translator versus a compiler makes it easier and faster to generate and
- debug C object-code rather than intermediate, assembler or machine code.  The
- translator design is based on the visitor pattern, allowing multiple passes
- over the abstract code-tree, which works well for incrementally adding new
- feature through additional visitor passes.  At the heart of the translator is
- the type resolver, which handles the polymorphic routine/type
- overload-resolution.  The Cforall runtime system is 100+ files and 11,000+
- lines of code, written in Cforall.  Currently, the Cforall runtime is the
- largest user of Cforall providing a vehicle to test the language features and
- implementation.  The Cforall tests are 290+ files and 27,000+ lines of code.
- The tests illustrate syntactic and semantic features in Cforall, plus a
- growing number of runtime benchmarks.  The tests check for correctness and are
- used for daily regression testing of commits (3800+).
-
-   Furthermore, the article lacks some related work.  Many proposed features
-   are present in functional languages such as Haskell, ML etc.  In particular,
-   the dealing of parametric polymorphism reminds me of Haskell.
+   Overloading requires the compiler to mangle a function's signature into its name in the object
+   file.  I'm pretty sure that this will complicate the build process of mixed Cforall/C projects.
+
+There is no complexity with building Cforall/C programs, and there is an existence proof because C++
+has name mangling for overloading and has no problem interacting with C.
+
+
+   I found the evaluation underwhelming.  There were only ~200 LoC ported from C to Cforall.  This
+   is too less to encounter potential caveats Cforall's type system might impose.
+
+We have clarified that the evaluation is not for the type system, but rather the underlying
+implementation approach for the parametric polymorphism. Section 9 now starts:
+
+ Cforall adds parametric polymorphism to C.  A runtime evaluation is performed to compare the cost
+ of alternative styles of polymorphism.  The goal is to compare just the underlying mechanism for
+ implementing different kinds of polymorphism.
+
+and ends with:
+
+ We conjecture these results scale across most generic data-types as the underlying polymorphic
+ implement is constant.
+ 
+
+   Also, how is the compiler implemented?  I guess, Cforall is a source-to-source compiler (from
+   Cforall to C).  But this is left in the dark.  What features are actually implemented?
+
+The following paragraph has been added to the introduction to address this comment:
+
+ All languages features discussed in this paper are working, except some advanced exception-handling
+ features.  Not discussed in this paper are the integrated concurrency-constructs and user-level
+ threading-library~\cite{Delisle18}.  Cforall is an open-source project implemented as an
+ source-to-source translator from Cforall to the gcc-dialect of C~\cite{GCCExtensions}, allowing it
+ to leverage the portability and code optimizations provided by gcc, meeting goals (1)--(3).
+ Ultimately, a compiler is necessary for advanced features and optimal performance.  The Cforall
+ translator is 200+ files and 46,000+ lines of code written in C/C++.  Starting with a translator
+ versus a compiler makes it easier and faster to generate and debug C object-code rather than
+ intermediate, assembler or machine code.  The translator design is based on the visitor pattern,
+ allowing multiple passes over the abstract code-tree, which works well for incrementally adding new
+ feature through additional visitor passes.  At the heart of the translator is the type resolver,
+ which handles the polymorphic routine/type overload-resolution.  The Cforall runtime system is 100+
+ files and 11,000+ lines of code, written in Cforall.  Currently, the Cforall runtime is the largest
+ user of Cforall providing a vehicle to test the language features and implementation.  The Cforall
+ tests are 290+ files and 27,000+ lines of code.  The tests illustrate syntactic and semantic
+ features in Cforall, plus a growing number of runtime benchmarks.  The tests check for correctness
+ and are used for daily regression testing of commits (3800+).
+
+
+   Furthermore, the article lacks some related work.  Many proposed features are present in
+   functional languages such as Haskell, ML etc.  In particular, the dealing of parametric
+   polymorphism reminds me of Haskell.
 
 The following paragraph has been added at the start of Section 10.1:
 
- ML~\cite{ML} was the first language to support parametric polymorphism.  Like
- Cforall, it supports universal type parameters, but not the use of assertions
- and traits to constrain type arguments.  Haskell~\cite{Haskell10} combines
- ML-style polymorphism, polymorphic data types, and type inference with the
- notion of type classes, collections of overloadable methods that correspond in
- intent to traits in Cforall.  Unlike Cforall, Haskell requires an explicit
- association between types and their classes that specifies the implementation
- of operations.  These associations determine the functions that are assertion
- arguments for particular combinations of class and type, in contrast to
- Cforall where the assertion arguments are selected at function call sites
- based upon the set of operations in scope at that point.  Haskell also
- severely restricts the use of overloading: an overloaded name can only be
- associated with a single class, and methods with overloaded names can only be
- defined as part of instance declarations.
-
-   Cforall's approach to tuples is also quite similar to many functional
-   languages.
+ ML~\cite{ML} was the first language to support parametric polymorphism.  Like Cforall, it supports
+ universal type parameters, but not the use of assertions and traits to constrain type arguments.
+ Haskell~\cite{Haskell10} combines ML-style polymorphism, polymorphic data types, and type inference
+ with the notion of type classes, collections of overloadable methods that correspond in intent to
+ traits in Cforall.  Unlike Cforall, Haskell requires an explicit association between types and
+ their classes that specifies the implementation of operations.  These associations determine the
+ functions that are assertion arguments for particular combinations of class and type, in contrast
+ to Cforall where the assertion arguments are selected at function call sites based upon the set of
+ operations in scope at that point.  Haskell also severely restricts the use of overloading: an
+ overloaded name can only be associated with a single class, and methods with overloaded names can
+ only be defined as part of instance declarations.
+
+
+   Cforall's approach to tuples is also quite similar to many functional languages.
 
 At the end of Section 10.2, we state:
 
- Tuples are a fundamental abstraction in most functional programming languages,
- such as Standard ML, Haskell}, and Scala, which decompose tuples using pattern
- matching.
+ Tuples are a fundamental abstraction in most functional programming languages, such as Standard ML,
+ Haskell}, and Scala, which decompose tuples using pattern matching.