Hmmm... it seems I didn't get Ladislav's message... anyway, I have
some comments on Elan's "mental model".
Hello [EMAIL PROTECTED]!
On 22-Lug-00, you wrote:
r>> From the point of a statement that is being evaluated, there
r>> exists a
r> hierarchy of "Effective Context Tables". The lowest Context
r> Table in this hierarchy will first be used to search for the
r> value of a word, and if the word is not found in this context
r> table, the search will continue in context tables at higher
r> levels in the context table hierarchy. The lowest table in the
r> context table hierarchy is the context table that was last
r> created, "last" in terms of previous statements that were
r> evaluated.
This was REBOL 1.x behaviour. REBOL 2.x is very different in this
regard; the word lookup is NOT done at runtime but by the function
BIND, and there is no context hierarchy.
Unfortunately, this cannot be proved with the current version of
REBOL. Older versions, such as 2.1, allowed changing the words
block of an object, and so manipulating the context table.
I proved back then that this worked:
>> obj: make object! [x: 1]
>> word: in obj 'x
== x
>> get word
== 1
>> change next first obj 'a
== []
>> get word
== 1
with the object context table modified:
>> print mold obj
make object! [
a: 1
]
while the current version shows:
>> print mold obj
make object! [
x: 1
]
I have to think up if I can find a different way to prove this.
Anyway, I can prove that there is no context hierarchy:
>> a: 1 b: 1 c: 1
== 1
>> obj1: make object! [
[ a: 2
[ obj2: make object! [
[ b: 2
[ obj3: make object! [
[ c: 2
[ ]
[ ]
[ ]
>> blk: [a b c]
== [a b c]
>> print blk
1 1 1
>> print bind blk in obj1/obj2/obj3 'self
1 1 2
If contexts where organized hierarchycally the output would have
been "2 2 2".
r> Multiple "Context Tables" At the time REBOL enters the
r> function a new "Context Table" becomes effective. This context
r> table, at this point in time, would like this:
r> word | value
r> x | 1
r> y | 2
This is actually created when the function is created, and is
always effective, even if it is changed every time the function is
called. You can refer to previous messages in this list by me,
Ladislav and Brian about the working of function contexts, in
particular in the case of recursive functions.
r> If REBOL created a private context table for the function at
r> the time the function was defined, then it will not be able to
r> retrieve a value for x, because the function was not evaluated
r> yet, and no value was assigned to x as yet.
Ah, ok, so did know this already. :-)
r> word | value
r> x | unassigned
Actually is:
word | value
x | unset!
r> What we should note here is that apparently REBOL remembered
r> all three context tables for the function f, even while it was
r> in the third (recursive) function call to f. In other words
r> the f function was temporarily associated with three context
r> tables. At the deepest recursion-level the two context tables
r> it acquired during the previous calls to f were remembered.
Ladislav suggested that only tha values are remembered, while the
context table is reused. So the function has still only one
context table in any time, but keeps a stack of values.
r> Then we 'a associated with the current-recursion level, and
r> subsequently called f recursively. If f continued to use its
r> previous context table, then, while x was set to a lower level
r> by virtue of the function call f (x - 1), a was not modified
r> yet, so 'a should continue to be associated with 1, the value
r> of recursion-level, during the privous call.
I think this does not prove that a new context table is created.
Creating a new context table would require a new binding of the
function body. Only the value column is stored in a stack and
reinitialized, as happens when the function is called the first
time.
Handling recursive functions this way is quite fast and simple.
Regards,
Gabriele.
--
Gabriele Santilli <[EMAIL PROTECTED]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
