[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
Modified:
pypy/dist/pypy/doc/draft-dynamic-language-translation.txt
Log:
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``.
+
+XXX
+
+
+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'*.
XXX
+Constant annotations
+~~~~~~~~~~~~~~~~~~~~
+
+XXX constant arguments to operations
+
+
Draft
~~~~~
@@ -1159,13 +1237,6 @@
lookup_filter(NonPbcAnnotation, class) = NonPbcAnnotation
-Prebuilt constants
-~~~~~~~~~~~~~~~~~~
-
-XXX
-
-XXX constant arguments to operations
-
Termination
~~~~~~~~~~~
@@ -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