[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