1.1 --- a/README.txt Tue Sep 23 00:33:01 2008 +0200
1.2 +++ b/README.txt Fri Sep 26 23:48:05 2008 +0200
1.3 @@ -1,167 +1,3 @@
1.4 -Namespace Definition
1.5 -====================
1.6 -
1.7 -Module attributes are defined either at the module level or by global
1.8 -statements.
1.9 -
1.10 -Class attributes are defined only within class statements.
1.11 -
1.12 -Instance attributes are defined only by assignments to attributes of self
1.13 -within __init__ methods.
1.14 -
1.15 -(These restrictions apply because such attributes are thus explicitly
1.16 -declared. Module and class attributes can also be finalised in this way in
1.17 -order to permit certain optimisations.)
1.18 -
1.19 -Potential Restrictions
1.20 -----------------------
1.21 -
1.22 -Names of classes and functions could be restricted to only refer to those
1.23 -objects within the same namespace. If redefinition were to occur, or if
1.24 -multiple possibilities were present, these restrictions could be moderated as
1.25 -follows:
1.26 -
1.27 - * Classes assigned to the same name could provide the union of their
1.28 - attributes. This would, however, cause a potential collision of attribute
1.29 - definitions such as methods.
1.30 -
1.31 - * Functions, if they share compatible signatures, could share parameter list
1.32 - definitions.
1.33 -
1.34 -Instruction Evaluation Model
1.35 -============================
1.36 -
1.37 -Programs use a value stack where evaluated instructions may save their
1.38 -results. A value stack pointer indicates the top of this stack. In addition, a
1.39 -separate stack is used to record the invocation frames. All stack pointers
1.40 -refer to the next address to be used by the stack, not the address of the
1.41 -uppermost element.
1.42 -
1.43 - Frame Stack Value Stack
1.44 - ----------- ----------- Address of Callable
1.45 - -------------------
1.46 - previous ...
1.47 - current ------> callable -----> identifier
1.48 - arg1 reference to code
1.49 - arg2
1.50 - arg3
1.51 - local4
1.52 - local5
1.53 - ...
1.54 -
1.55 -Loading local names is a matter of performing frame-relative accesses to the
1.56 -value stack.
1.57 -
1.58 -Invocations and Argument Evaluation
1.59 ------------------------------------
1.60 -
1.61 -When preparing for an invocation, the caller first sets the invocation frame
1.62 -pointer. Then, positional arguments are added to the stack such that the first
1.63 -argument positions are filled. A number of stack locations for the remaining
1.64 -arguments specified in the program are then reserved. The names of keyword
1.65 -arguments are used (in the form of table index values) to consult the
1.66 -parameter table and to find the location in which such arguments are to be
1.67 -stored.
1.68 -
1.69 - fn(a, b, d=1, e=2, c=3) -> fn(a, b, c, d, e)
1.70 -
1.71 - Value Stack
1.72 - -----------
1.73 -
1.74 - ... ... ... ...
1.75 - fn fn fn fn
1.76 - a a a a
1.77 - b b b b
1.78 - ___ ___ ___ --> 3
1.79 - ___ --> 1 1 | 1
1.80 - ___ | ___ --> 2 | 2
1.81 - 1 ----------- 2 ----------- 3 -----------
1.82 -
1.83 -Conceptually, the frame can be considered as a collection of attributes, as
1.84 -seen in other kinds of structures:
1.85 -
1.86 -Frame for invocation of fn:
1.87 -
1.88 - 0 1 2 3 4 5
1.89 - code a b c d e
1.90 - reference
1.91 -
1.92 -However, where arguments are specified positionally, such "attributes" are not
1.93 -set using a comparable approach to that employed with other structures.
1.94 -Keyword arguments are set using an attribute-like mechanism, though, where the
1.95 -position of each argument discovered using the parameter table.
1.96 -
1.97 -Where the target of the invocation is known, the above procedure can be
1.98 -optimised slightly by attempting to add keyword argument values directly to
1.99 -the stack:
1.100 -
1.101 - Value Stack
1.102 - -----------
1.103 -
1.104 - ... ... ... ... ...
1.105 - fn fn fn fn fn
1.106 - a a a a a
1.107 - b b b b b
1.108 - ___ ___ ___ --> 3
1.109 - 1 1 1 | 1
1.110 - 2 1 | 2
1.111 - 3 -----------
1.112 -
1.113 - (reserve for (add in-place) (add in-place) (evaluate) (store by
1.114 - parameter c) index)
1.115 -
1.116 -Method Invocations
1.117 -------------------
1.118 -
1.119 -Method invocations incorporate an implicit first argument which is obtained
1.120 -from the context of the method:
1.121 -
1.122 - method(a, b, d=1, e=2, c=3) -> method(self, a, b, c, d, e)
1.123 -
1.124 - Value Stack
1.125 - -----------
1.126 -
1.127 - ...
1.128 - method
1.129 - context of method
1.130 - a
1.131 - b
1.132 - 3
1.133 - 1
1.134 - 2
1.135 -
1.136 -Although it could be possible to permit any object to be provided as the first
1.137 -argument, in order to optimise instance attribute access in methods, we should
1.138 -seek to restrict the object type.
1.139 -
1.140 -Verifying Supplied Arguments
1.141 -----------------------------
1.142 -
1.143 -In order to ensure a correct invocation, it is also necessary to check the
1.144 -number of supplied arguments. If the target of the invocation is known at
1.145 -compile-time, no additional instructions need to be emitted; otherwise, the
1.146 -generated code must test for the following situations:
1.147 -
1.148 - 1. That the number of supplied arguments is equal to the number of expected
1.149 - parameters.
1.150 -
1.151 - 2. That no keyword argument overwrites an existing positional parameter.
1.152 -
1.153 -Default Arguments
1.154 ------------------
1.155 -
1.156 -Some arguments may have default values which are used if no value is provided
1.157 -in an invocation. Such defaults are initialised when the function itself is
1.158 -initialised, and are used to fill in any invocation frames that are known at
1.159 -compile-time.
1.160 -
1.161 -Tuples, Frames and Allocation
1.162 ------------------------------
1.163 -
1.164 -Using the approach where arguments are treated like attributes in some kind of
1.165 -structure, we could choose to allocate frames in places other than a stack.
1.166 -This would produce something somewhat similar to a plain tuple object.
1.167 -
1.168 Optimisations
1.169 =============
1.170