Index: doc/papers/general/Paper.tex
===================================================================
--- doc/papers/general/Paper.tex	(revision f86c8e5ecaac53c31e0a371cf9d091a3f8148761)
+++ doc/papers/general/Paper.tex	(revision b51e5fdb602c1dba2eccbae649d9e6465ad8f6b3)
@@ -592,7 +592,7 @@
 [ q, r ] = div( 13.5, 5.2 );				$\C{// assign into tuple}$
 \end{cfa}
-Clearly, this approach is straightforward to understand and use;
+This approach is straightforward to understand and use;
 therefore, why do few programming languages support this obvious feature or provide it awkwardly?
-The answer is that there are complex consequences that cascade through multiple aspects of the language, especially the type-system.
+To answer, there are complex consequences that cascade through multiple aspects of the language, especially the type-system.
 This section show these consequences and how \CFA handles them.
 
@@ -813,5 +813,5 @@
 where @[5, "hello"]@ is flattened, giving argument list @5, "hello"@, and @T@ binds to @int@ and @U@ binds to @const char@.
 Tuples, however, may contain polymorphic components.
-For example, a plus operator can be written to add two triples together.
+For example, a plus operator can be written to sum two triples.
 \begin{cfa}
 forall( otype T | { T ?+?( T, T ); } ) [T, T, T] ?+?( [T, T, T] x, [T, T, T] y ) {
@@ -847,8 +847,8 @@
 As such, @ttype@ variables are also called \newterm{argument packs}.
 
-Like variadic templates, the main way to manipulate @ttype@ polymorphic functions is via recursion.
+Like variadic templates, @ttype@ polymorphic functions are primarily manipulated via recursion.
 Since nothing is known about a parameter pack by default, assertion parameters are key to doing anything meaningful.
 Unlike variadic templates, @ttype@ polymorphic functions can be separately compiled.
-For example, a generalized @sum@ function written using @ttype@:
+For example, a generalized @sum@ function:
 \begin{cfa}
 int sum$\(_0\)$() { return 0; }
@@ -2648,6 +2648,6 @@
 We justify the given line count by noting that many object-oriented languages do not allow implementing new interfaces on library types without subclassing or wrapper types, which may be similarly verbose.
 
-Raw line-count, however, is a fairly rough measure of code complexity;
-another important factor is how much type information the programmer must manually specify, especially where that information is not checked by the compiler.
+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.
 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.
@@ -2766,7 +2766,7 @@
 Finally, we demonstrate that \CFA performance for some idiomatic cases is better than C and close to \CC, showing the design is practically applicable.
 
-There is ongoing work on a wide range of \CFA feature extensions, including arrays with size, runtime type-information, virtual functions, user-defined conversions, concurrent primitives, and modules.
-(While all examples in the paper compile and run, a public beta-release of \CFA will take another 8--12 months to finalize these additional extensions.)
-In addition, there are interesting future directions for the polymorphism design.
+There is ongoing work on a wide range of \CFA features, including arrays with size, runtime type-information, virtual functions, user-defined conversions, concurrent primitives, and modules.
+While all examples in the paper compile and run, a public beta-release of \CFA will take another 8--12 months to finalize these extensions.
+There are also interesting future directions for the polymorphism design.
 Notably, \CC template functions trade compile time and code bloat for optimal runtime of individual instantiations of polymorphic functions.
 \CFA polymorphic functions use dynamic virtual-dispatch;