Index: doc/rob_thesis/variadic.tex
===================================================================
--- doc/rob_thesis/variadic.tex	(revision f92aa323eb5582c8fbbb703c08db45bad1558125)
+++ doc/rob_thesis/variadic.tex	(revision 0eb185575bf22730aa7d4caf71c4758583ee159b)
@@ -12,5 +12,5 @@
 In addition, C requires the programmer to hard code all of the possible expected types.
 As a result, it is cumbersome to write a function that is open to extension.
-For example, a simple function which sums $N$ @int@s,
+For example, a simple function to sum $N$ @int@s,
 \begin{cfacode}
 int sum(int N, ...) {
@@ -27,5 +27,5 @@
 sum(3, 10, 20, 30);  // need to keep counter in sync
 \end{cfacode}
-The @va_list@ type is a special C data type that abstracts variadic argument manipulation.
+The @va_list@ type is a special C data type that abstracts variadic-argument manipulation.
 The @va_start@ macro initializes a @va_list@, given the last named parameter.
 Each use of the @va_arg@ macro allows access to the next variadic argument, given a type.
@@ -34,9 +34,9 @@
 In the case where the provided type is not compatible with the argument's actual type after default argument promotions, or if too many arguments are accessed, the behaviour is undefined \cite[p.~81]{C11}.
 Furthermore, there is no way to perform the necessary error checks in the @sum@ function at run-time, since type information is not carried into the function body.
-Since they rely on programmer convention rather than compile-time checks, variadic functions are generally unsafe.
+Since they rely on programmer convention rather than compile-time checks, variadic functions are unsafe.
 
 In practice, compilers can provide warnings to help mitigate some of the problems.
-For example, GCC provides the @format@ attribute to specify that a function uses a format string, which allows the compiler to perform some checks related to the standard format specifiers.
-Unfortunately, this approach does not permit extensions to the format string syntax, so a programmer cannot extend the attribute to warn for mismatches with custom types.
+For example, GCC provides the @format@ attribute to specify that a function uses a format string, which allows the compiler to perform some checks related to the standard format-specifiers.
+Unfortunately, this approach does not permit extensions to the format-string syntax, so a programmer cannot extend the attribute to warn for mismatches with custom types.
 
 As a result, C's variadic functions are a deficient language feature.
@@ -79,7 +79,7 @@
 Similarly, in order to pass 0 variadic arguments, an explicit empty tuple must be passed into the argument list, otherwise the exact matching rule would not have an argument to bind against.
 
-It should be otherwise noted that the addition of an exact matching rule only affects the outcome for polymorphic type binding when tuples are involved.
+It should be otherwise noted that the addition of an exact matching rule only affects the outcome for polymorphic type-binding when tuples are involved.
 For non-tuple arguments, exact matching and flattening and structuring are equivalent.
-For tuple arguments to a function without polymorphic formal parameters, flattening and structuring work whenever an exact match would have worked, since the tuple is flattened and implicitly restructured to its original structure.
+For tuple arguments to a function without polymorphic formal-parameters, flattening and structuring work whenever an exact match would have worked, since the tuple is flattened and implicitly restructured to its original structure.
 Thus there is nothing to be gained from permitting the exact matching rule to take effect when a function does not contain polymorphism and none of the arguments are tuples.
 
@@ -161,5 +161,5 @@
   return x+y;
 }
-forall(otype T1, otype T2, otype T3, ttype Params, otype R
+forall(otype T1, otype T2, otype T3, otype R, ttype Params
   | summable(T1, T2, T3)
   | { R sum(T3, Params); })
@@ -184,5 +184,5 @@
 \CFA does not need an ellipsis in either case, since the type class @ttype@ is only used for variadics.
 An alternative design is to use an ellipsis combined with an existing type class.
-This approach was not taken because the largest benefit of the ellipsis token in \CC is the ability to expand a parameter pack within an expression, e.g., in fold expressions, which requires compile-time knowledge of the structure of the parameter pack, which is not available in \CFA.
+This approach was not taken because the largest benefit of the ellipsis token in \CC is the ability to expand a parameter pack within an expression, \eg, in fold expressions, which requires compile-time knowledge of the structure of the parameter pack, which is not available in \CFA.
 \begin{cppcode}
 template<typename... Args>
@@ -224,8 +224,8 @@
 Array * x = new(1, 2, 3);
 \end{cfacode}
-The @new@ function provides the combination of type-safe @malloc@ with a constructor call, so that it becomes impossible to forget to construct dynamically allocated objects.
+In the call to @new@, @Array@ is selected to match @T@, and @Params@ is expanded to match @[int, int, int, int]@. To satisfy the assertions, a constructor with an interface compatible with @void ?{}(Array *, int, int, int)@ must exist in the current scope.
+
+The @new@ function provides the combination of type-safe @malloc@ with a constructor call, so that it becomes impossible to forget to construct dynamically-allocated objects.
 This approach provides the type-safety of @new@ in \CC, without the need to specify the allocated type, thanks to return-type inference.
-
-In the call to @new@, @Array@ is selected to match @T@, and @Params@ is expanded to match @[int, int, int, int]@. To satisfy the assertions, a constructor with an interface compatible with @void ?{}(Array *, int, int, int)@ must exist in the current scope.
 
 \section{Implementation}
@@ -240,5 +240,5 @@
 }
 \end{cfacode}
-Generates the following
+generates the following
 \begin{cfacode}
 void *malloc(long unsigned int _sizeof_T, long unsigned int _alignof_T);
@@ -267,5 +267,5 @@
 \end{cfacode}
 The constructor for @T@ is called indirectly through the adapter function on the result of @malloc@ and the parameter pack.
-The variable that was allocated and constructed is then returned from @new@.
+The variable that is allocated and constructed is then returned from @new@.
 
 A call to @new@
@@ -337,5 +337,5 @@
 }
 \end{cfacode}
-Generates
+generates the following
 \begin{cfacode}
 void print_variadic(
@@ -382,5 +382,5 @@
 print("x = ", 123, ".\n");
 \end{cfacode}
-Generates the following
+generates the following
 \begin{cfacode}
 void print_string(const char *x){
