[REBOL] Series essay Re:(7)
Yes, that's what I tried to say. You're welcome. Ladislav - Pùvodní zpráva - Od: [EMAIL PROTECTED] Komu: [EMAIL PROTECTED] Odesláno: 28. prosince 1999 16:43 Pøedmìt: [REBOL] Series essay Re:(6) [EMAIL PROTECTED] wrote: Hi, Joel, although not been asked, trying to answer some questions. 1) The model of binding Gabriele (not Gabrielle) [sigh...] It seems I am unable to type these days without making a typo! [My apollogies, Gabriele!] proposed was proposed as a hypothesis, that could explain the Rebol behaviour. Since then it has succeeded to explain every situation encountered and to make valid predictions, so it's validity is much less questionable than validity of any other binding model proposed. Gabriele's email to which I was responding certainly expressed some ideas that were helpful to me. My questions were intended to help me understand it better. I appreciate your assistance in that regard. So, let me do a sanity check by attempting to answer the questions I raised, based on my understanding of what you and Gabriele have said. You've persuaded me that one part of that concept does NOT apply to REBOL -- that of searching a chain of environments... There is no "chain of environments". Each word directly refers to its own context. e == [a b c] print e 1 2 12 c ** Script Error: c has no value. ** Where: c same? 'c third e == false The 'c at the third element of 'e ['s value] had been bound to the local context of a function (value of 'f), and was therefore a different word from a global 'c (although spelled the same). h: func [][bind e third e print e] h 20 21 12 H. Within 'f (where we've bound 'c) the words 'a and 'b would have evaluated globally. However, attempting to bind 'e back to that context doesn't restore 'a and 'b (in e!) to refer to the global 'a and 'b. Precisely because global 'a and 'b aren't in the context to which the third element of 'e ['s value] is bound, and therefore aren't changed by the 'bind within 'h ['s value]. bind e 'f == [a b c] print e ** Script Error: c has no value. ** Where: c a == 1 print first e a print get first e 1 The last one is the only one I'm still trying to understand. Running the following (in a fresh REBOL console) highlights my question. a: 1 == 1 b: 2 == 2 e: [a b c] == [a b c] print e ** Script Error: c has no value. ** Where: c f: func [n /local c][c: n bind e 'c print e] f ** Script Error: f is missing its n argument. ** Where: f f 99 1 2 99 print e 1 2 99 bind e 'e == [a b c] print e ** Script Error: c has no value. ** Where: c What I think you've said is that the bind in f affects only the third element of e because the other elements refer to words not in the context used for the bind. c is bound, but a and b are left alone. OTOH, the last bind above affects all of a, b, and c, because it the target context is the global context. Therefore, a and b get bound back to a context where they already have values, but c gets bound to a context where it does NOT have a value. Did I interpret your description correctly? Thanks for your feedback (and patience) ! -jn-
[REBOL] Series essay Re:(7)
Don't know if you tried this, Joel, but here's a few more interesting lines to add to your example. a: 1 == 1 b: 2 == 2 e: [a b c] == [a b c] print e ** Script Error: c has no value. ** Where: c f: func [n /local c][c: n bind e 'c print e] f ** Script Error: f is missing its n argument. ** Where: f f 99 1 2 99 print e 1 2 99 bind e 'e == [a b c] print e ** Script Error: c has no value. ** Where: c ; (more) f 99 1 2 99 print e 1 2 99 ; 'c is restored to the 'e context c: 12 bind e 'e == [a b c] print e 1 2 12 ; 'e binds to 'c in the this context unset 'c print e ** Script Error: c has no value. ** Where: c ; no 'c in this context now f 99 1 2 99 print e 1 2 99 bind/copy e 'e == [a b c] print e 1 2 99 ; with the copy refinement, 'e binds to the 'c in the 'f local context. f 98 1 2 98 print e 1 2 98 ; and when the 'c in the the 'f local context changes, so does the 'c in the 'e local context a: 65 65 print e 65 2 98 ; and we are still bound to the orignal 'a So to retain a word set to a value in a local context, we can use the 'bind/copy refinement. At first, I was thinking we were copying the 'c from the 'f context. But I guess we're really copying the 'c from the 'e context. Bind is operating in the block outside of 'e and so 'c does not exist to it. But I guess the /copy refinement recreates the local 'c so that bind can use it. It doesn't seem to be a "copy" in the usual sense though, since it appears to be the same value first created in 'f. Just as a value can be shared between words, perhaps a word can be shared among contexts. -Ted.
[REBOL] Series essay Re:(7)
Jerry, What is 'x supposed to be in your example? block: copy [] repeat i 4 [use [x] [x: i * i append block 'x]] == [x x x x] print block 1 4 9 16 do x/1 ** Script Error: x has no value. ** Where: do x/1 do x/2 ** Script Error: x has no value. ** Where: do x/2 I didn't have any global named 'x, nor did the initialization of 'block create one. Did you perhaps have one left over from some prior activity? -jn- Gerald Goertzel wrote: Gabriele, I think, using your example, that I have found a bug in REBOL. block: copy [] repeat i 4 [use [x] [x: i * i append block 'x]] == [x x x x] do x/1 == 1 do x/2 == 4 x/1 = x/2 == true x/1 == x/2 == true What do you think? Is it a bug? Jerry
[REBOL] Series essay Re:(7)
See remarks below: Russell [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 28, 1999 4:34 PM Subject: [REBOL] Series essay Re:(6) Gabriele, I think, using your example, that I have found a bug in REBOL. block: copy [] repeat i 4 [use [x] [x: i * i append block 'x]] == [x x x x] do x/1 I get an error here; x has no value. Did you mean to use 'block in that expression and below, whereever 'x appears? do block/1 returns 1, do block/2 returns 4. Thus it appears that even though x has no value globally, it can be "done", ie, evaluated. Interestingly, if you precede your "code" with x: 25, it retains that value after executing your first code line. So the x's that appear in block [x x x x] differ from the global x with value 25. == 1 do x/2 == 4 x/1 = x/2 == true x/1 == x/2 == true What do you think? Is it a bug? Jerry
[REBOL] Series essay Re:(7)
On 12/27/1999 at 4:08 PM [EMAIL PROTECTED] wrote:
{{In the standard implementation model, Pascal local variables are
allocated on the stack upon entry to a procedure, and deallocated
upon exit from the procedure. There's no way to make a local
var from one procedure refer to the content of a local var from a
different procedure (except via pointers, and then one gets into
the danger of the "dangling reference" problem).
OTOH, by using 'bind it IS possible to make the word/value
association that exists within one context available to another.
That's a very large difference, IMHO.}}
Well, allocating locals on the stack is certainly one way to do it, but
the language itself only requires the behavior. And most
implementations, I think, clearly defined whether a local variable was
initialized or not. In the Borland implementation, the answer was not,
since they included a keyword ABSOLUTE which let you define two
variables names at the same memory location. Meanwhile, I also believe
C has a static keyword that preserves local variables between function
calls, which implies those locals at least are stored outside the
stack. "Nothing new under the sun."
But, back on thread, since words can be bound as functions as well as
variables, I imagine the implementation model is probably a tree
structure, such as is used to scope nested subroutines. Unlike many
other languages, REBOL needs to store "variables" and "functions" in
the same space, since a word can be one and then the other, and all
words can be evaluated, whether they store a scalar or a script. I
can't just put a Pascal variable on a line by itself and expect the
compiler to do something with it!
I also wonder if some of the behavior we see in local variables
retaining values across function calls is by design or happenstance.
The documentation doesn't seem to specify whether local variables are
initialized. At the first evaluation, they seem to start out as none,
but then ...dunno.
-T.
Incidentally,. I'm really enjoying your posts, Joel.
