[pypy-svn] r18363 - pypy/dist/pypy/doc

arigo at codespeak.net arigo at codespeak.net
Tue Oct 11 10:28:09 CEST 2005

Author: arigo
Date: Tue Oct 11 10:28:05 2005
New Revision: 18363

Talk about classes and instances and pbcs.

Modified: pypy/dist/pypy/doc/draft-dynamic-language-translation.txt
--- pypy/dist/pypy/doc/draft-dynamic-language-translation.txt	(original)
+++ pypy/dist/pypy/doc/draft-dynamic-language-translation.txt	Tue Oct 11 10:28:05 2005
@@ -662,9 +662,9 @@
 * List(*v*) -- list; *v* is a variable summarizing the items of the list
   (there is one such term per variable);
-* Callable(*set*) -- where the *set* is a subset of the (finite) set of
-  all functions, all classes, and all pairs of a class and a function
-  (written ``class.f``).
+* Pbc(*set*) -- where the *set* is a subset of the (finite) set of all
+  `Prebuilt Constants`_, defined below.  This set includes all the
+  callables of the user program: functions, classes, and methods.
 * None -- stands for the singleton ``None`` object of Python.
@@ -673,8 +673,8 @@
 which stands for "either the object described or ``None``".  We use it
 to propagate knowledge about which variable, after translation to C,
 could ever contain a NULL pointer.  (More precisely, there are a
-NullableStr, nullable instances, and nulllable callables, and all lists
-are implicitely assumed to be nullable).
+NullableStr, nullable instances, and nullable Pbcs, and all lists are
+implicitely assumed to be nullable).
 Each annotation corresponds to a family of run-time Python object; the
 ordering of the lattice is essentially the subset order.  Formally, it
@@ -688,7 +688,7 @@
 * Inst(*subclass*) <= Inst(*class*) -- for any class and subclass;
-* Callable(*subset*) <= Callable(*set*);
+* Pbc(*subset*) <= Pbc(*set*);
 * a <= b -- for any annotation *a* with a nullable twin *b*;
@@ -706,8 +706,8 @@
             /   NullableStr   |         |      |
           Int     /   \       |       (lists)  |
           /     Str    \  (instances)   |      |
-    NonNegInt     \     \     |         |  (callables)
-          \       Char   \    |\       /      /     
+    NonNegInt     \     \     |         |   (Pbcs)
+          \       Char   \    |\       /      /
           Bool      \     \   | \     /      /
             \        \     `----- None -----/
              \        \       |   /        /
@@ -752,9 +752,9 @@
             \            \     \   /     /            /
              '------------'--- None ----'------------'
-The callables form a classical finite set-of-subsets lattice.  In
-practice, we consider ``None`` as a degenerated callable, so the None
-annotation is actually Callable({None}).
+The Pbcs form a classical finite set-of-subsets lattice.  In practice,
+we consider ``None`` as a degenerated prebuilt constant, so the None
+annotation is actually Pbc({None}).
 We should mention (but ignore for the sequel) that all annotations also
 have a variant where they stand for a single known object; this
@@ -1002,6 +1002,59 @@
 As with `merge_into`_, it identifies the two lists.
+Prebuilt constants
+The ``Pbc`` annotations play a special role in our approach.  They
+regroup in a single family most of the constant user-defined objects
+that pre-exist the annotation phase.  This includes the functions and
+classes defined in the user program, but also some other objects that
+have been built while the user program was initializing itself.
+The presence of the latter kind of objects -- which comes with a number
+of new problems to solve -- is a distinguishing property of the idea of
+analysing a live program instead of static source code.  All the user
+objects that pre-exist the annotation phase are divided in two further
+families: the "frozen prebuilt constants" ones and the "prebuilt
+instances".  By default, instances of some user-defined class that
+happens to pre-exist annotation have no constantness requirement on
+their own; after annotation and possibly compilation, these instances
+will continue to behave as regular mutable instances of that class.
+These prebuilt instances are decribed in another section (`Constant
+annotations`_).  However, the user program can give a hint that forces
+the annotator to consider the object as a "frozen prebuilt constant".
+The object is then considered as a now-immutable container of
+attributes.  It looses its object-oriented aspects and its class becomes
+irrelevant -- it was only useful to the user program to build the object
+up to its current state.
+In summary, the prebuilt constants are:
+* all functions ``f`` of the user program (including the ones appearing
+  as methods);
+* all classes ``C`` of the user program;
+* all frozen prebuilt constants;
+For convenience, we add the following objects to the above set:
+* for each function ``f`` and class ``C``, a "potential bound method"
+  object written ``C.f``, used below to handle method calls;
+* the singleton None object (a special case of frozen prebuilt constant).
+The annotation ``Pbc(*set*)`` stands for an object that belongs to the
+specified *set* of prebuilt constant objects, which is a subset of all
+the prebuilt constant objects.
+In practice, the set of all prebuilt constants is not fixed in advance,
+but grows while annotation discovers new functions and classes and
+frozen user objects; only the objects that are still alive will be
+included in the set, leaving out the ones that were only relevant during
+the initialization phase of the program.
 Classes and instances
@@ -1038,7 +1091,7 @@
 program point are instances of a user-defined common base class, i.e.
 not ``object``.
-We recall from `definition of V`_ that we have a variable ``v_C.attr``
+Remember from `definition of V`_ that we have a variable ``v_C.attr``
 for each class ``C`` and each possible attribute name ``attr``.  The
 annotation state *(b,E)* has the following meaning on these variables:
@@ -1068,12 +1121,37 @@
                E' = E union (v_C.attr ~ v_D.attr)  for all D subclass of C
                merge_into(z, v_C.attr)
-Note the similarity with the lists' ``getitem`` and ``setitem``, in
+The purpose of ``lookup_filter`` is to avoid loosing precision in method
+calls.  Indeed, as described more precisely in `Constant annotations`_
+below, if ``attr`` names a method of the class ``C`` then the binding
+``b(v_C.attr)`` is a ``Pbc`` that includes all the "potental bound
+method" objects ``D.f``, for each subclass ``D`` of ``C`` where a
+function ``f`` is present under the name ``attr``.
+if ``attr`` is a method defined on XXX::
+    lookup_filter(Pbc(set), class) = Pbc(newset) where
+        we only keep in newset the non-methods, and the following methods:
+         * the ones bound to a strict subclass of 'class', and
+         * among the methods bound the 'class' or superclasses, only the
+             one from the most derived class.
+    lookup_filter(NonPbcAnnotation, class) = NonPbcAnnotation
+Note the similarity with the ``getitem`` and ``setitem`` of lists, in
 particular the usage of the auxiliary variable *z'*.
+Constant annotations
+XXX constant arguments to operations
@@ -1159,13 +1237,6 @@
     lookup_filter(NonPbcAnnotation, class) = NonPbcAnnotation
-Prebuilt constants
-XXX constant arguments to operations
@@ -1173,12 +1244,12 @@
 The lattice is finite, although its size depends on the size of the
-program.  The List part has the same size as *V*, and the Callable part
-is exponential on the number of callables.  However, in this model a
-chain of annotations (where each one is larger than the previous) cannot
-be longer than::
+program.  The List part has the same size as *V*, and the Pbc part is
+exponential on the number of prebuilt constants.  However, in this model
+a chain of annotations (where each one is larger than the previous)
+cannot be longer than::
-    max(5, number-of-callables + 3, depth-of-class-hierarchy + 3).
+    max(5, number-of-pbcs + 3, depth-of-class-hierarchy + 3).
 In the extended lattice used in practice it is more difficult to compute
 an upper bound.  Such a bound exists -- some considerations can even

More information about the Pypy-commit mailing list