From 15bdd37447686c8cfa46e61a7d31e05bfe4f60db Mon Sep 17 00:00:00 2001
From: Joao Dias
Date: Mon, 26 Jul 2010 18:06:50 -0400
Subject: [PATCH] Wibbles.
---
paper/dfopt.tex | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/paper/dfopt.tex b/paper/dfopt.tex
index 4cb7b08..24429fd 100644
--- a/paper/dfopt.tex
+++ b/paper/dfopt.tex
@@ -637,9 +637,9 @@ As~a concrete example, we show constant propagation with constant
folding.
On the left we show a basic block; in the middle we show
facts that hold between statements (or \emph{nodes})
-in the block; and at
+in the block; and on
the right we show the result of transforming the block
-based on the assertions:
+based on the facts:
\begin{verbatim}
Before Facts After
------------{}-------------
@@ -707,8 +707,8 @@ replaces the node @x:=e@ with a no-op.
\seclabel{simple-tx}
\paragraph{Interleaved transformation and analysis.}
-Our first example \emph{interleaves} analysis (constant propagation)
-and transformation (constant folding).
+Our first example \emph{interleaves} analysis and transformation.
+% constant propagation is a transformation, not an analysis
Interleaving makes it far easier to write effective analyses.
If, instead, we \emph{first} analyzed the block
and \emph{then} transformed it, the analysis would have to ``predict''
@@ -886,7 +886,7 @@ data `Node e x where
The type of a node specifies \emph{at compile time} whether the node is open or
closed on entry and exit. Concretely,
-the node type constructor has kind @*->*->*@, where the two type parameters
+the type constructor for a node has kind @*->*->*@, where the two type parameters
are type-level flags, one for entry and one for exit.
Such a type parameter may be instantiated only with type @O@~(for
open) or type~@C@ (for closed).
@@ -1062,7 +1062,7 @@ the type @MaybeO O a@ is isomorphic to~@a@, while
the type @MaybeO C a@ is isomorphic to~@()@.
\item
The \emph{body} of the graph is a collection of closed/closed blocks.
-To~facilitate traversal of the graph, we represent a body as a finite
+To~facilitate traversal of the graph, we represent the body as a finite
map from label to block.
\simon{{\tt LabelMap} not defined in Fig 2}
\item
@@ -3248,7 +3248,7 @@ so when implemented in \hoopl.
\paragraph{Examining the API}
-We hope the our presentation of the API in \secref{api} speaks for
+We hope that our presentation of the API in \secref{api} speaks for
itself,
but there are a couple of properties we think are worth highlighting.
First, it's a good sign that the API provides many higher-order
@@ -3493,7 +3493,7 @@ a client wanted one set of
unique names for labels and a different set for registers?
Moreover, a client might want a rewrite to perform other actions
entirely that could not be anticipated by \hoopl{}.
-For exampe, in order to judge the effectiveness of an optimization,
+For example, in order to judge the effectiveness of an optimization,
a client might want to log how many rewrites take place, or in what
functions they take place.
As~a more ambitious example, \citet{runciman:increasing-prs} describes
--
1.9.1