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

pedronis at codespeak.net pedronis at codespeak.net
Wed May 31 17:05:22 CEST 2006


Author: pedronis
Date: Wed May 31 17:05:21 2006
New Revision: 28007

Modified:
   pypy/extradoc/talk/dls2006/paper.tex
Log:
[D|T] -> \cite



Modified: pypy/extradoc/talk/dls2006/paper.tex
==============================================================================
--- pypy/extradoc/talk/dls2006/paper.tex	(original)
+++ pypy/extradoc/talk/dls2006/paper.tex	Wed May 31 17:05:21 2006
@@ -707,7 +707,7 @@
 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 [T].
+complete list is described in document \cite{T}.
 
 The type system moreover comes with a family of rules, which for every
 operation and every sensible combination of input types describes the
@@ -751,14 +751,15 @@
 
 It is outside the scope of the present paper to describe the type
 inference engine and the rules more formally.  The difficult points
-involve mutable containers -- e.g.\ initially empty list that are filled
-somewhere else -- and the discovery of instance attributes -- in Python,
-classes do not declare upfront a fixed set of attributes for their
-instances, let alone their types.  Both these examples require
-sophisticated reflowing techniques that invalidate existing types in
-already-annotated basic blocks, to account for the influence of more
-general types coming indirectly from a possibly distant part of the
-program.  The reader is referred to [D] for more information.
+involve mutable containers -- e.g.\ initially empty list that are
+filled somewhere else -- and the discovery of instance attributes --
+in Python, classes do not declare upfront a fixed set of attributes
+for their instances, let alone their types.  Both these examples
+require sophisticated reflowing techniques that invalidate existing
+types in already-annotated basic blocks, to account for the influence
+of more general types coming indirectly from a possibly distant part
+of the program.  The reader is referred to technical report \cite{D}
+for more information.
 
 
 \subsection{Termination and complexity}
@@ -792,7 +793,7 @@
 order of 5 to 10 minutes, and basic blocks are typically only reflown a
 handful of times, providing a close-to-linear practical complexity.
 
-We give formal termination and correctness proofs in [D], as well as
+We give formal termination and correctness proofs in \cite{D}, as well as
 worst-case bounds and some experimental evidence of their practical
 irrelevance.
 



More information about the Pypy-commit mailing list