[pypy-svn] pypy documentation-cleanup: (lac, cfbolz): kill theory.rst, which is very high-level and thus a bit useless. replace by wikipedia links.
cfbolz
commits-noreply at bitbucket.org
Mon Apr 25 12:01:15 CEST 2011
Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch: documentation-cleanup
Changeset: r43564:f11a3a95cc27
Date: 2011-04-25 11:58 +0200
http://bitbucket.org/pypy/pypy/changeset/f11a3a95cc27/
Log: (lac, cfbolz): kill theory.rst, which is very high-level and thus a
bit useless. replace by wikipedia links.
diff --git a/pypy/doc/objspace.rst b/pypy/doc/objspace.rst
--- a/pypy/doc/objspace.rst
+++ b/pypy/doc/objspace.rst
@@ -469,7 +469,7 @@
resulting pair of basic strings. This is similar to the C++ method
overloading resolution mechanism (but occurs at runtime).
-.. _multimethods: theory.html#multimethods
+.. _multimethods: http://en.wikipedia.org/wiki/Multimethods
Multimethod slicing
@@ -556,7 +556,7 @@
.. _`found here` : getting-started-dev.html#tracing-bytecode-and-operations-on-objects
-.. _`Abstract Interpretation`: theory.html#abstract-interpretation
+.. _`Abstract Interpretation`: http://en.wikipedia.org/wiki/Abstract_interpretation
.. _`traceconfig.py`: ../tool/traceconfig.py
@@ -588,7 +588,7 @@
appear in some next operation. This technique is an example of `Abstract
Interpretation`_.
-.. _`Abstract Interpretation`: theory.html#abstract-interpretation
+.. _`Abstract Interpretation`: http://en.wikipedia.org/wiki/Abstract_interpretation
For example, if the placeholder ``v1`` is given as the argument to the above
function, the bytecode interpreter will call ``v2 = space.mul(space.wrap(3),
diff --git a/pypy/doc/cleanup.rst b/pypy/doc/cleanup.rst
--- a/pypy/doc/cleanup.rst
+++ b/pypy/doc/cleanup.rst
@@ -29,8 +29,6 @@
statistic/index.rst
- theory.rst
-
translation-aspects.rst
docindex.rst
diff --git a/pypy/doc/docindex.rst b/pypy/doc/docindex.rst
--- a/pypy/doc/docindex.rst
+++ b/pypy/doc/docindex.rst
@@ -165,7 +165,6 @@
.. _`coding guide`: coding-guide.html
.. _`architecture`: architecture.html
.. _`getting started`: getting-started.html
-.. _`theory`: theory.html
.. _`bytecode interpreter`: interpreter.html
.. _`EU reports`: index-report.html
.. _`Technical reports`: index-report.html
@@ -223,7 +222,7 @@
`objspace/thunk.py`_ the `thunk object space`_, providing unique object features
-`objspace/flow/`_ the FlowObjSpace_ implementing `abstract interpretation`
+`objspace/flow/`_ the FlowObjSpace_ implementing `abstract interpretation`_
`objspace/std/`_ the StdObjSpace_ implementing CPython's objects and types
@@ -285,7 +284,7 @@
.. _`What PyPy can do for your objects`: objspace-proxies.html
.. _`Stackless and coroutines`: stackless.html
.. _StdObjSpace: objspace.html#the-standard-object-space
-.. _`abstract interpretation`: theory.html#abstract-interpretation
+.. _`abstract interpretation`: http://en.wikipedia.org/wiki/Abstract_interpretation
.. _`rpython`: coding-guide.html#rpython
.. _`type inferencing code`: translation.html#the-annotation-pass
.. _`RPython Typer`: translation.html#rpython-typer
diff --git a/pypy/doc/translation.rst b/pypy/doc/translation.rst
--- a/pypy/doc/translation.rst
+++ b/pypy/doc/translation.rst
@@ -104,7 +104,7 @@
.. _`PDF color version`: image/translation.pdf
.. _`bytecode evaluator`: interpreter.html
-.. _`abstract interpretation`: theory.html#abstract-interpretation
+.. _`abstract interpretation`: http://en.wikipedia.org/wiki/Abstract_interpretation
.. _`Flow Object Space`: objspace.html#the-flow-object-space
.. _`interactive interface`: getting-started-dev.html#try-out-the-translator
.. _`translatorshell.py`: ../../../../pypy/bin/translatorshell.py
diff --git a/pypy/doc/theory.rst b/pypy/doc/theory.rst
deleted file mode 100644
--- a/pypy/doc/theory.rst
+++ /dev/null
@@ -1,91 +0,0 @@
-.. include:: crufty.rst
-
- .. ^^ old ideas; we're not doing it this way any more
-
-===================================
-Techniques used in PyPy
-===================================
-
-.. contents::
-
-
-.. _`abstract interpretation`:
-
-Abstract Interpretation
-=======================
-
-Abstract Interpretation is a general technique which consists of an
-interpreter that follows the bytecode instructions of a user program, just
-like a normal interpreter does, but with abstract objects instead of concrete
-ones. Remember that in PyPy this is done by using alternate object spaces with
-the same bytecode interpreter main loop.
-
-As a theoretical example, the most abstract object space would be the one manipulating the most abstract objects that you could imagine: they are all equivalent, because we have abstracted away any information about the object. There is actually only one of them left, and we could call it "the object". In Python terms, an AbstractObjectSpace could use None for all its wrapped objects. Any operation between wrapped objects gives None again as the wrapped result -- there is nothing else it could give anyway. So when you have said that the add method of AbstractObjectSpace takes None and None and returns None you have said everything.
-
-The point of such an object space is for example to check the bytecode. The
-bytecode interpreter will really run your bytecode, just with completely
-abstract arguments. If there is no problem then you are sure that the bytecode
-is valid. You could also record, during this abstract interpretation, how much
-the stack ever grows; that would give you a fool-proof method of computing or
-checking the co_stacksize argument of a code object. (There are subtleties
-which I won't describe here, but that's the basic idea.)
-
-Typically, however, abstract object spaces are a (little) bit less abstract, still maintaining a minimal amount of information about the objects. For example, a wrapped object could be represented by its type. You then define the object space's add to return int when the two arguments are int and int. That way, you abstractedly call a function with the input argument's types and what the interpreter will do is a type inference. (Here also there are subtle problems, even besides the remark that integer operations can overflow and actually return longs in a real Python implementation.)
-
-As an example of more abstract object spaces you have the ones with finite domain, i.e. with a finite number of different possible wrapped objects. For example, you can use True and False as wrapped values to denote the fact that the object is, respectively, a non-negative integer or anything else. In this way you are doing another kind of type inference that just tells you which variables will only ever contain non-negative integers.
-
-In PyPy, the FlowObjSpace_ uses the abstract interpretation technique to generate a control flow graph of the functions of RPython_ programs.
-
-In its `more formal definition`_, Abstract Interpretation typically
-considers abstract objects that are organized in a lattice_: some of
-these objects are more (or less) abstract than others, in the sense that
-they represent less (or more) known information; to say that this forms
-a lattice essentially means that any two abstract objects have
-well-defined unions and intersections (which are again abstract
-objects).
-
-.. _FlowObjSpace: objspace.html#the-flow-object-space
-.. _RPython: coding-guide.html#restricted-python
-.. _`more formal definition`: http://en.wikipedia.org/wiki/Abstract_interpretation
-.. _lattice: http://en.wikipedia.org/wiki/Lattice_%28order%29
-
-
-Multimethods
-============
-
-A "multimethod" is the generalization of the OOP notion of "method".
-Theoretically, a method is a "message name" and signature attached to a
-particular base class, which is implemented in the class or its subclasses.
-To do a "method call" means to send a message to an object, using a message
-name and actual arguments. We call "message dispatch" the operation of
-finding which actual implementation is suitable for a particular call. For
-methods, a message is dispatched by looking up the class of the "self" object,
-and finding an implementation in that class, or in its base classes, in a
-certain order.
-
-A multimethod is a message name and signature that can have implementations
-that depend not only on the class of the first "self" argument, but on the
-class of several arguments. Because of this we cannot use Python's nice model
-of storing method implementations as functions, in the attributes of the
-class.
-
-Here is a common implementation of multimethods: they are instances of a
-specific MultiMethod class, and the instances are callable (there is a
-__call__ operator on MultiMethod). When a MultiMethod is called, a dispatch
-algorithm is used to find which, among the registered implementations, is the
-one that should be called; this implementation is then immediately called. The
-most important difference with normal methods is that the MultiMethod object
-to call is no longer syntactically attached to classes. In other words,
-whereas a method is called with ``obj.somemethod(args)``, a multimethod is
-called much like a function, e.g. ``dosomething(obj1, obj2, obj3...)``. You
-have to find the MultiMethod object ``dosomething`` in some namespace; it is
-no longer implicitly looked up in the namespace of the "self" object.
-
-PyPy contains two different implementations of multimethods: a `quite general
-one`_ written in RPython_ for the purposes of the StdObjSpace_, and a `short
-two-arguments-dispatching one`_ used internally by the annotator_.
-
-.. _`quite general one`: http://codespeak.net/svn/pypy/dist/pypy/objspace/std/multimethod.py
-.. _StdObjSpace: objspace.html#the-standard-object-space
-.. _`short two-arguments-dispatching one`: http://codespeak.net/svn/pypy/dist/pypy/tool/pairtype.py
-.. _annotator: translation.html#annotator
More information about the Pypy-commit
mailing list