[EMAIL PROTECTED] wrote:
>
> On 12/16/1999 at 12:17 AM [EMAIL PROTECTED] wrote:
> [...]
> > On the other hand, I prefer to keep the vocabulary needed to
> > describe REBOL to a minimum. I also like to exploit the similarity
> > of principles, to keep the volume of information needed to reason
> > about REBOL to a minimum.
>
> I think that the effort to find an adequate terminology is quite reasonable.
> It can't be considered as the opposite of being simple. Actually, the best
> terminology is, IMHO, a terminology, that is simple and correct.
>
Einstein is quoted as saying, "Everything should be as simple as
possible, but no simpler!" I agree with Ladislav that "simple and
correct" is optimal. I'd go further and insist that "correct" is
better than "too simple and therefore incorrect".
>
> (Scope means the part of the code where you can use A and B to access the
> data. The possibilities are "global" vs. "local".)
>
Quite right. The terms "global" and "local" are normally used in
computing science to indicate restrictions on the visibility of a
variable. In the illustration:
>> g: func [x] [print b return x + 2]
>> f: func [a /local b] [a: a + 1 b: a * 2 return g a]
>> a: 99
== 99
>> b: 98
== 98
>> f 2
98
== 5
>> a
== 99
>> b
== 98
the fact that 'b is local to 'f simply means that any reference to
the word 'b inside 'f refers to a variable that is distinct from any
'b that may exist outside of 'f. OTOH, 'g does not declare 'b as
local, therefore any reference to 'b in 'g refers to the 'b that is
defined outside of 'g.
The value printed when 'f calls 'g is 98, because that is the value
of the globally-defined 'b. Even though this occurs during a time
when 'f is being executed, the 'b that is local to 'f cannot be
"seen" by 'g.
Let's consider now another version of the Mystery Function that has
been discussed in this thread.
>> container: ["" "x"]
== ["" "x"]
This word just holds a block of data. The first element of the block
is a reference to an empty string; the second element is a reference
to a string of length 1.
>> f: func [/local a] [a: first container append a second
container print a]
Here our Mystery Function is altered to use {first container} and
{second container} instead of {""} and {"x"}
>> f
x
>> f
xx
>> f
xxx
>> f
xxxx
>> source container
container: ["xxxx" "x"]
I assume that this surprises no-one. Now consider one slight change.
>> container: ["" "x"]
== ["" "x"]
>> a-init: first container
== ""
>> a-incr: second container
== "x"
>> f: func [/local a][a: a-init append a a-incr print a]
>> f
x
>> f
xx
>> f
xxx
>> container
== ["xxx" "x"]
Are we still unsurprised? 'a is initialized by a-init (at the
second element of the body of 'f) which REFERS to an initially
empty string. When 'a (which now refers to that same initially
empty string) is modified, the string to which it refers is
modified. As the second element of 'container refers to that
same string, the modifications show up when we examine 'container.
Finally, in:
>> f: func [/local a][a: "" append a "x" print a]
>> f
x
>> f
xx
>> f
xxx
>> source f
f: func [/local a][a: "xxx" append a "x" print a]
the body of 'f contains a string at the second position. When
the function is invoked, 'a is initialized to refer to that string.
When 'a is modified, that string is modified. Therefore, when we
continue to invoke 'f, that string continues to be modified.
This has NOTHING to do with "local" vs "global", because we're
not talking about the scope of access of a variable. The body of
'f is just a block, so the appearance of {""} just puts a reference
to an empty string in the second position of the body of 'f. a'
is not initialized to a freshly-created empty string, nor to a
copy of a globally-available empty string literal/constant, but
simply to the second element of the body of 'f.
To demonstrate this point, consider:
>> f: func [/local a][a: pick second get 'f 13 append a "x" print
a exit ""]
>> f
x
>> f
xx
>> f
xxx
>> source f
f: func [/local a][a: pick second get 'f 13 append a "x" print a
exit "xxx"]
-jn-
