[pypy-svn] r29999 - pypy/extradoc/talk/dls2006

[pedronis at codespeak.net]

Author: pedronis
Date: Wed Jul 12 20:16:56 2006
New Revision: 29999

Modified:
   pypy/extradoc/talk/dls2006/paper.tex
Log:
remove the lattice figures to get again down to 12 pages.

I'm done for today, please review my changes. 

I still need to add a reference tough, 
will resubmit a first time tomorrow.



Modified: pypy/extradoc/talk/dls2006/paper.tex
==============================================================================
--- pypy/extradoc/talk/dls2006/paper.tex	(original)
+++ pypy/extradoc/talk/dls2006/paper.tex	Wed Jul 12 20:16:56 2006
@@ -597,23 +597,15 @@
 objects are the concrete Python objects of the various built-in types:
 lists, dictionaries, and so on.  By opposition, the Flow Object Space is
 really an abstract domain.  It handles objects that are placeholders.
-Its lattice order (actually a join-semilattice only) is shown in
-figure \ref{flowlattice}.
 
-\begin{figure*}
-\centering
-\includegraphics[scale=0.667]{image/flowlattice.pdf}
-\caption{the lattice order of the flow object space.}
-\label{flowlattice}
-\end{figure*}
-
-This order is extremely simple, because most actual analysis is delayed
-to the next phase, the type inference engine.  The objects are either
-\textit{Variables}, which are pure placeholders for entirely unknown values,
-or \textit{Constants} with a concrete Python object as value.  The order places
-Variable as the top, and keeps all \textit{Constants} unordered.  Thus if two
-different constants merge during abstract interpretation, we immediately
-widen them to Variable.
+Its lattice order (actually a join-semilattice only) is extremely
+simple, because most actual analysis is delayed to the next phase, the
+type inference engine.  The objects are either \textit{Variables},
+which are pure placeholders for entirely unknown values, or
+\textit{Constants} with a concrete Python object as value.  The order
+places Variable as the top, and keeps all \textit{Constants}
+unordered.  Thus if two different constants merge during abstract
+interpretation, we immediately widen them to Variable.
 
 In conjunction with the Flow Object Space, the bytecode interpreter of
 PyPy thus performs abstract interpretation of Python bytecodes from
@@ -672,13 +664,6 @@
 
 \subsection{The Annotator}
 
-\begin{figure*}
-\centering
-\includegraphics[scale=0.667]{image/lattice1.pdf}
-\caption{the overall lattice.}
-\label{latticeoverall}
-\end{figure*}
-
 The type inference engine, which we call the \textit{annotator}, is the central
 component of the front-end part of the translation process.  Given a
 program considered as a family of control flow graphs, the annotator
@@ -782,26 +767,15 @@
       \texttt{None}; resp. an instance or \texttt{None}.
 \end{itemize}
 
-Figures \ref{latticeoverall} and \ref{latticedetail} show how these
-types are ordered to form a lattice -- we generally use its structure of
-join-semilattice only, but we will see in section \ref{precision}
-a use case for the \textit{meet}.
-Not shown on the figures are the list terms, which are simply
-unordered with each other, and the Pbcs, which form a
-classical finite set-of-subsets lattice.  In addition, we have left
-out a number of other annotations that are irrelevant for the basic
-description of the annotator and straightforward to handle:
-$Dictionary$, $Tuple$, $Float$, $UnicodePoint$, $Iterator$, etc.  The
-complete list is described in \cite{T}.
-
-\begin{figure}
-\centering
-\includegraphics[scale=0.667]{image/lattice2.pdf}
-\caption{the part about instances and nullable instances, assuming a
-  simple class hierarchy with only two direct subclasses of
-  \texttt{object}.}
-\label{latticedetail}
-\end{figure}
+These types are ordered to form a lattice -- we generally use its
+structure of join-semilattice only, but we will see in section
+\ref{precision} a use case for the \textit{meet}. Pbcs form a
+classical finite set-of-subsets lattice, class annotations are ordered
+by inheritance.  We have left out a number of other annotations that
+are irrelevant for the basic description of the annotator and
+straightforward to handle: $Dictionary$, $Tuple$, $Float$,
+$UnicodePoint$, $Iterator$, etc.  The complete list and order is
+described in \cite{T}.
 
 The type system moreover comes with a family of rules, which for every
 operation and every meaningful combination of input types describes the