1.1 --- a/README.txt Sat Jul 26 01:16:02 2008 +0200
1.2 +++ b/README.txt Sun Jul 27 02:00:31 2008 +0200
1.3 @@ -24,209 +24,6 @@
1.4 * Functions, if they share compatible signatures, could share parameter list
1.5 definitions.
1.6
1.7 -Data Structures
1.8 -===============
1.9 -
1.10 -The fundamental "value type" is a pair of references: one pointing to the
1.11 -referenced object represented by the interchangeable value; one referring to
1.12 -the context of the referenced object, typically the object through which the
1.13 -referenced object was acquired as an attribute.
1.14 -
1.15 -Value Layout
1.16 -------------
1.17 -
1.18 - 0 1
1.19 - object context
1.20 - reference reference
1.21 -
1.22 -Acquiring Values
1.23 -----------------
1.24 -
1.25 -Values are acquired through name lookups and attribute access, yielding
1.26 -the appropriate object reference together with a context reference as
1.27 -indicated in the following table:
1.28 -
1.29 - Type of Access Context Notes
1.30 - -------------- ------- -----
1.31 -
1.32 - Local name Preserved Functions provide no context
1.33 -
1.34 - Global name Preserved Modules provide no context
1.35 -
1.36 - Class-originating Accessor Class accessor preserves the stored
1.37 - attribute -or- context; instance accessor overrides
1.38 - Preserved the stored context if it is null or
1.39 - belongs to the instance's class
1.40 - hierarchy
1.41 -
1.42 - Instance-originating Preserved Methods retain their original context
1.43 - attribute
1.44 -
1.45 -There may be some scope for simplifying the above, to the detriment of Python
1.46 -compatibility, since the unbound vs. bound methods situation can be confusing.
1.47 -
1.48 -Manipulating Values
1.49 --------------------
1.50 -
1.51 -According to the table describing value acquisition, different instructions
1.52 -must implement different operations when acquiring values:
1.53 -
1.54 - Instruction Purpose Context Operations
1.55 - ----------- ------- ------------------
1.56 -
1.57 - LoadConst Load class, function, Combine null context with loaded
1.58 - module, constant object
1.59 -
1.60 - LoadAddress Load attribute from Classes, functions and modules
1.61 - known object stored as cause the loaded attribute to be
1.62 - an attribute retrieved unchanged; whereas
1.63 - constants (representing instances)
1.64 - cause the constant to override the
1.65 - attribute's own context (since all
1.66 - attributes should belong to the
1.67 - constant's class hierarchy)
1.68 -
1.69 - LoadAttr Load attribute from Attributes with null contexts or
1.70 - instance stored as an contexts compatible with the
1.71 - attribute instance cause loaded attributes
1.72 - to combine the instance as context
1.73 - with the object from the
1.74 - attribute; other attributes have
1.75 - their context preserved
1.76 -
1.77 - LoadAttrIndex Load attribute from Classes, functions and modules as
1.78 - unknown object stored the unknown object accessor cause
1.79 - as an attribute the loaded attribute to be
1.80 - retrieved unchanged; whereas
1.81 - instances cause the LoadAttr rules
1.82 - to apply
1.83 -
1.84 -Consequently, a certain amount of run-time testing is required for both
1.85 -LoadAttr and LoadAttrIndex.
1.86 -
1.87 -Objects
1.88 --------
1.89 -
1.90 -Since classes, functions and instances are all "objects", each must support
1.91 -certain features and operations in the same way.
1.92 -
1.93 -The __class__ Attribute
1.94 ------------------------
1.95 -
1.96 -All objects support the __class__ attribute:
1.97 -
1.98 -Class: refers to the type class (type.__class__ also refers to the type class)
1.99 -Function: refers to the function class
1.100 -Instance: refers to the class instantiated to make the object
1.101 -
1.102 -Invocation
1.103 -----------
1.104 -
1.105 -The following actions need to be supported:
1.106 -
1.107 -Class: create instance, call __init__ with instance, return object
1.108 -Function: call function body, return result
1.109 -Instance: call __call__ method, return result
1.110 -
1.111 -Structure Layout
1.112 -----------------
1.113 -
1.114 -A suitable structure layout might be something like this:
1.115 -
1.116 - Identifier Address Type Object ...
1.117 -
1.118 - 0 1 2 3 4
1.119 - classcode invocation __class__ attribute ...
1.120 - reference reference reference
1.121 -
1.122 -Here, the classcode refers to the attribute lookup table for the object. Since
1.123 -classes and instances share the same classcode, they might resemble the
1.124 -following:
1.125 -
1.126 -Class C:
1.127 -
1.128 - 0 1 2 3 4
1.129 - code for C __new__ class type attribute ...
1.130 - reference reference reference
1.131 -
1.132 -Instance of C:
1.133 -
1.134 - 0 1 2 3 4
1.135 - code for C C.__call__ class C attribute ...
1.136 - reference reference reference
1.137 - (if exists)
1.138 -
1.139 -The __new__ reference would lead to code consisting of the following
1.140 -instructions:
1.141 -
1.142 - create instance for C
1.143 - call C.__init__(instance, ...)
1.144 - return instance
1.145 -
1.146 -If C has a __call__ attribute, the invocation "slot" of C instances would
1.147 -refer to the same thing as C.__call__.
1.148 -
1.149 -For functions, the same general layout applies:
1.150 -
1.151 -Function f:
1.152 -
1.153 - 0 1 2 3 4
1.154 - code for code class attribute ...
1.155 - function reference function reference
1.156 - reference
1.157 -
1.158 -Here, the code reference would lead to code for the function. Note that the
1.159 -function locals are completely distinct from this structure and are not
1.160 -comparable to attributes.
1.161 -
1.162 -For modules, there is no meaningful invocation reference:
1.163 -
1.164 -Module m:
1.165 -
1.166 - 0 1 2 3 4
1.167 - code for m (unused) module type attribute ...
1.168 - reference (global)
1.169 - reference
1.170 -
1.171 -Both classes and modules have code in their definitions, but this would be
1.172 -generated in order and not referenced externally.
1.173 -
1.174 -Invocation Operation
1.175 ---------------------
1.176 -
1.177 -Consequently, regardless of the object an invocation is always done as
1.178 -follows:
1.179 -
1.180 - get invocation reference (at object+1)
1.181 - jump to reference
1.182 -
1.183 -Additional preparation is necessary before the above code: positional
1.184 -arguments must be saved to the parameter stack, and keyword arguments must be
1.185 -resolved and saved to the appropriate position in the parameter stack.
1.186 -
1.187 -Attribute Operations
1.188 ---------------------
1.189 -
1.190 -Attribute access needs to go through the attribute lookup table. Some
1.191 -optimisations are possible and are described in the appropriate section.
1.192 -
1.193 -One important aspect of attribute access is the appropriate setting of the
1.194 -context in the acquired attribute value. From the table describing the
1.195 -acquisition of values, it is clear that the principal exception is that where
1.196 -a class-originating attribute is accessed on an instance. Consequently, the
1.197 -following algorithm could be employed once an attribute has been located:
1.198 -
1.199 - 1. If the attribute's context is a special value, indicating that it should
1.200 - be replaced upon instance access, then proceed to the next step;
1.201 - otherwise, acquire both the context and the object as they are.
1.202 -
1.203 - 2. If the accessor is an instance, use that as the value's context, acquiring
1.204 - only the object from the attribute.
1.205 -
1.206 -Where accesses can be determined ahead of time (as discussed in the
1.207 -optimisations section), the above algorithm may not necessarily be employed in
1.208 -the generated code for some accesses.
1.209 -
1.210 Instruction Evaluation Model
1.211 ============================
1.212