[pypysvn] 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/draftdynamiclanguagetranslation.txt
Log:
Talk about classes and instances and pbcs.
Modified: pypy/dist/pypy/doc/draftdynamiclanguagetranslation.txt
==============================================================================
 pypy/dist/pypy/doc/draftdynamiclanguagetranslation.txt (original)
+++ pypy/dist/pypy/doc/draftdynamiclanguagetranslation.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 runtime 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 setofsubsets lattice. In
practice, we consider ``None`` as a degenerated callable, so the None
annotation is actually Callable({None}).
+The Pbcs form a classical finite setofsubsets 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 userdefined objects
+that preexist 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 preexist the annotation phase are divided in two further
+families: the "frozen prebuilt constants" ones and the "prebuilt
+instances". By default, instances of some userdefined class that
+happens to preexist 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 nowimmutable container of
+attributes. It looses its objectoriented 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 userdefined 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 nonmethods, 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, numberofcallables + 3, depthofclasshierarchy + 3).
+ max(5, numberofpbcs + 3, depthofclasshierarchy + 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 Pypycommit
mailing list