Index: doc/generic_types/generic_types.tex
===================================================================
--- doc/generic_types/generic_types.tex	(revision 3ed64ff574fb9f8a1492007a38d642b4c9a389bd)
+++ doc/generic_types/generic_types.tex	(revision b2daebd4c266a105c2ce540f4f6ad6144590981a)
@@ -1,4 +1,5 @@
-% take of review (for line numbers) and anonymous (for anonymization) on submission
-\documentclass[format=acmlarge, anonymous, review]{acmart}
+% take off review (for line numbers) and anonymous (for anonymization) on submission
+% \documentclass[format=acmlarge, anonymous, review]{acmart}
+\documentclass[format=acmlarge, review]{acmart}
 
 \usepackage{listings}	% For code listings
@@ -150,7 +151,5 @@
 \begin{lstlisting}
 forall(otype T)
-T identity(T x) {
-    return x;
-}
+T identity(T x) { return x; }
 
 int forty_two = identity(42); // T is bound to int, forty_two == 42
@@ -163,7 +162,5 @@
 \begin{lstlisting}
 forall(otype T | { T twice(T); })
-T four_times(T x) {
-    return twice( twice(x) );
-}
+T four_times(T x) { return twice( twice(x) ); }
 
 double twice(double d) { return d * 2.0; } // (1)
@@ -257,7 +254,5 @@
 typedef list *list_iterator;
 
-lvalue int *?( list_iterator it ) {
-    return it->value;
-}
+lvalue int *?( list_iterator it ) { return it->value; }
 \end{lstlisting}
 
@@ -410,4 +405,5 @@
   return ret;
 }
+
 sum(3, 10, 20, 30);  // must keep initial counter argument in sync
 \end{lstlisting}
@@ -679,4 +675,5 @@
 void print(int x) { printf("%d", x);  }
 void print(S s) { print("{ ", s.x, ",", s.y, " }"); }
+
 print("s = ", (S){ 1, 2 }, "\n");
 \end{lstlisting}
@@ -693,4 +690,5 @@
   return ((T*)malloc( sizeof(T) )){ p }; // construct into result of malloc
 }
+
 Pair(int, char) * x = new(42, '!');
 \end{lstlisting}
@@ -794,4 +792,8 @@
 In conclusion, the authors' design for generic types and tuples imposes minimal runtime overhead while still supporting a full range of C features, including separately-compiled modules. There is ongoing work on a wide range of \CFA{} feature extensions, including reference types, exceptions, and concurrent programming primitives. In addition to this work, there are some interesting future directions the polymorphism design could take. Notably, \CC{} template functions trade compile time and code bloat for optimal runtime of individual instantiations of polymorphic functions. \CFA{} polymorphic functions, by contrast, use an approach that is essentially dynamic virtual dispatch. The runtime overhead of this approach is low, but not as low as \CC{} template functions, and it may be beneficial to provide a mechanism for particularly performance-sensitive code to close this gap. Further research is needed, but two promising approaches are to allow an annotation on polymorphic function call sites that tells the translator to create a template-specialization of the function (provided the code is visible in the current translation unit) or placing an annotation on polymorphic function definitions that instantiates a version of the polymorphic function specialized to some set of types. These approaches are not mutually exclusive, and would allow these performance optimizations to be applied only where most useful to increase performance, without suffering the code bloat or loss of generality of a template expansion approach where it is unnecessary.
 
+\begin{acks}
+This work is supported in part by a corporate partnership with \grantsponsor{Huawei}{Huawei Ltd.}{http://www.huawei.com}\ and the first author's \grantsponsor{NSERC-PGS}{NSERC PGS D}{http://www.nserc-crsng.gc.ca/Students-Etudiants/PG-CS/BellandPostgrad-BelletSuperieures_eng.asp} scholarship.
+\end{acks}
+
 \bibliographystyle{ACM-Reference-Format}
 \bibliography{generic_types}