Hi Ladislav,
you wrote:
>
>I think that the effort to find an adequate terminology is quite reasonable.
Absolutely.
>It can't be considered as the opposite of being simple.
Certainly, searching for an adequate terminology is not the opposite of
being simple. The search can result in a simple terminology or a
terminology that complicates matters. Two criteria I can think of are
a) The choice of words ("View" and "underlying data" is by far not a bad
choice). Do you need to master greek, latin and geek to be comfortable with
the vocabulary introduced with the terminology?
b) The words chosen to describe the language slice the language up, in a
manner of speaking. How close are the concepts introduced by the
terminology to the language constructs and the logic of their
relationships? Will theoretical constructs have to be introduced to
reconstruct the logic implemented by the language, because it was sliced up
improperly to begin with? I'm not sure how "View" and "underlying data" do
with respect to this criteria.
>Actually, the best
>terminology is, IMHO, a terminology, that is simple and correct.
Of course.
>
>Let's get to the above example, but let's use a little bit different code:
>
>f: func [/local a b] [ a: "" b: copy "" for i 1 6 1 [append a i append b i]
>print a print b]
>>> f
>123456
>123456
>>> f
>123456123456
>123456
>>> f
>123456123456123456
>123456
>
>Let's have a look at A and B above. We see, that they are exactly the same
>as long as "scope" is concerned.
[snipped part saying the both A and B are local to the function, which
indeed they are.]
>So, where's the difference?
>
The difference has nothing to do with 'a or 'b.
>We must turn to a different notion, the "lifetime" of data, which can be
>described in terms like "static" vs. "dynamic".
>
>So, where is the difference between A and B? The correct answer is:
>
>B is created dynamically
Both 'a and 'b are set-words. And they are both being created the exact
same way, as literal set-words (due to the colon following 'a and 'b
respectively, a: , b: ).
If 'b was dynamically created, we should something like:
>> to-set-word 'b
== b:
or
>> make set-word! 'b
== b:
No, a: and b: are created the exact same way, as set-word! literals.
>when the interpreter encounters the expression:
>
>copy ""
>
>, which is a sign of dynamic data creation.
See, the problem with your terminology is that by speaking of the expression
b: copy ""
as a dynamic creation of 'b, you are hiding what is actually happening here
and replacing it by something that is not happening. That is misleading.
b: is no different from a:. b: is a literal value of type set-word:
>> block: [a: "" b: copy ""]
== [a: b:]
>> type? first block
== set-word!
>> first block
== a:
>> type? third block
== set-word!
>> third block
== b:
Note that the combination of a word (i.e. here 'a or 'b) with a colon is
one, single token. First and third recognize it as such. First and third do
not report 'a or 'b as tokens, with the colon being a second, distinct
token. The token is a: or b: respectively.
To make sure that this is understood: a: is not two separate tokens, the
word 'a, plus a creation operator ":". Instead a: is one token, it is a
value with a specific datatype, namely the type set-word!.
When a set-word is evaluated, as here, it requires an argument it will
reference. When REBOL searches the input stream for an argument that the
set-word 'b will reference, it encounters the word copy. It then goes
through the process of reducing 'copy to its value, evaluating copy's value
and creating a copy of "". That copy of "" becomes the value referenced by
'b.
The difference you associate with 'a and 'b is not a difference between 'a
and 'b, it is a difference with respect to the expressions used to create
the VALUES referenced by 'a and 'b. 'a references a literal string. 'b
references a local string, namely the one returned by the function copy
that processes the literal string "" as its argument. That string is the
local result of the expression copy "", and, when it is referenced by 'b,
it is local to the context of the word 'b.
>
>, but A is not created when the interpreter encounters the expression:
>
>a: ""
The word 'a is for sure created, when REBOL encounters a: in the input
stream. The value 'a, because it has the type set-word!, then becomes a
reference to the literal string "".
>
>, because in the latter expression the data known as A only get it's name A.
Data does not get a name. In REBOL the opposite applies. The set-word! 'a
is being set as a reference to some data, namely the value "", which is a
literal string. The difference is important, in that the relationship
between the word 'a referencing the value "" and the value "" stand in a
remote and very loose connection.
Specifically, the literal string does not know of and doesn't care about
the fact that it is being referenced by 'a. Referring to it as "named data"
is misleading, because it suggests that there are two types of values,
named and unnamed. There is no distinction on the value, with respect to
whether it is being referenced by a word, which you refer to as having
"named" the "data".
>
>The legitimate question arises: "When is the A data really created?"
Here the same thing applies. There is no harm in thinking of "the 'a
string", as long as you remain clear of the fact that the string does not
have the attribute 'a, nor does 'a have the attribute string, their
relationship is only that of a reference from 'a to the literal string.
That reference is not an attribute of 'a nor is that reference an attribute
of the literal string. The literal string remains the exact same literal
string, whether or not it is referenced by 'a. The word 'a remains the
exact same word 'a, whether or not it is a reference to that literal
string. The existence of a reference relationship between 'a and the
literal string is an additional entity, whose existence does not modify
what 'a is or what the string is.
There are rules that apply to 'a by virtue of being a word, there are rules
that apply to the literal string by virtue of the string being a literal
string, and there are rules that apply to the reference between 'a and the
literal string, by virtue of there being a reference.
Again, words, values and references are three distinct entities, where each
entity obeys its own rules.
As soon as you use a formulation like "named string", or "the string A", or
the "A data", you begin confusing which entity obeys which rules.
Using these kinds of formulations you begin discussing rules that control
the reference between 'a and the literal string, as though they were rules
controlling the literal string, or as though they were rules controlling
the word 'a. That leads to confusion. And that leads to misinterpreting or
being surprised by REBOL's behavior.
>
>The correct answer IMHO is as follows: data A (although not having that
>name) gets created when the interpreter LOAD's the F's code.
>Any
>modification to A data then persists until the data doesn't get
>garbage-collected, which may happen e.g. when F gets GC'd.
>
I believe you have a typo here. You meant the modification persists *until*
the data *is* garbage-collected, or *as long as* the data *is not*
garbage-collected, right?
That is not quite true. it would be more precise to say that the literal
string persists as long as it is referenced by a word whose context
continues to be active, either directly, as in a reference assignment, or
indirectly, as in a word referencing a block, which in turn contains the
literal string:
f: func [/local a b] [
a: ""
b: copy ""
for i 1 6 1 [
append a i append b i
]
print a print b
]
>> global-a: pick second :f 2
== ""
>> insert global-a "this is global-a"
== ""
>> f
this is global-a123456
123456
>> unset 'f
>> recycle
>> global-a
== "this is global-a123456"
You see how associating the string with the word 'a by using such
formulations as "data A", or "data named A", misleads you to express the
relationship between 'a and the literal string it references such that the
existence of the literal string becomes dependent on 'a or one of the
entities associated with 'a (such as the block in which 'a is embedded or
the function), when indeed the existence of the literal string does not
depend on the continued existence of 'a, the block in which 'a is
associated with the string, or even the function, whose body block is that
block, in which 'a is associated with the literal string.
In my example, I forced the function 'f to be garbage collected. Needless
to say, the literal string happily continued its existence, because it was
referenced by a word that I called global-a. Using your formulation, this
would come as a surprise, since the naming convention you use, "data A", in
no way suggests that "data A" may be preserved independent of the continued
existence of A. If the name goes, wouldn't one expect that the data went
with it? Well, it didn't.
>So, the difference between A and B lies in the fact, that the creation of B
>is "dynamic" as opposed to A, where the creation is "static" and the notions
>of "global" vs. "local" are misleading in this case.
>
This is a wrong explanation. You are expressing the difference in the
phenomenon we observe as a difference between how 'a and 'b came about. But
the difference of the phenomenon has nothing to do with 'a and 'b. The
difference in the phenomenon has only to do with a difference between the
values referenced by 'a and 'b.
1. 'a and 'b were "created" the exact same way! They were both created as
set-words by entering a: and b: into REBOLS input stream respectively.
2. The difference in the behavior we observe is a difference between the
values referenced by 'a and 'b and not a difference regarding 'a and 'b.
a) The value referenced by 'a is one and the same literal string, each time
the function f is evaluated.
b) The string referenced by 'b is a different, newly created empty string
returned by the word copy each time the function f is evaluated.
It's important to make this distinction. If you're going to understand
REBOL, you have to be able to identify, which rules are responsible for an
observed behavior.
The behavior of REBOL at this point could have been
1. a result of rules that apply to words. It wasn't.
2. a result of rules that apply to values. It was.
3. a result of rules that apply to references. It was.
When you say:
>So, the difference between A and B lies in the fact, that the creation of B
>is "dynamic" as opposed to A, where the creation is "static" and the notions
>of "global" vs. "local" are misleading in this case.
there is nothing in your statement that suggests that the observed behavior
is a result the combined influence of two types of rules:
1. rules that apply to values, and
2. rules that apply to references
and not rules that apply to words.
Why does the literal string referenced by value retain its values?
Rules that apply to values:
Because the string is a literal string.
Rules that apply to references:
In REBOL it is a property of literal strings that they are global and
therefore persistent. Modifications made to a literal string persist beyond
the local context of the function, because of an attribute of references:
REBOL automatically establishes a reference to any literal string from the
global context.
So far we have explained why we find the elements we inserted into the
string during the previous evaluation of the function, when the function is
evaluated anew.
We have not yet explained why we don't find the elements the same elements
in the string referenced by 'b.
Why does the word 'b reference an empty string, each time the function f is
evaluated? Because b is assigned as a reference to a new, empty string each
time the function f is evaluated. The difference here also has to do with
a) rules of referencing
b) the value referenced by 'b, which in this particularly case is the copy
of an empty literal string.
Quite precisely:
Which string is referenced by the word 'b changes each time the function is
evaluated, because
1. the function copy is evaluated anew at each evaluation of 'f,
2. and therefore returns a new string as a copy of the empty literal string
supplied as its argument.
3. So, you see that it is NOT something that has to do with the nature of 'b
4. nor is it something that has to with the properties of the string 'b
references, which brings about the modification,
5. but rather it has to do with WHICH string 'b references, namely
6.'b references a DIFFERENT string each time the function is evaluated and
that different string is
7, a copy of an empty string.
If we were to agree with your formulation that the difference we observe in
the function's behavior with respect to the strings referenced by 'a and 'b
is due to
>the creation of B
>is "dynamic" as opposed to A, where the creation is "static"
then we would be very surprised by the following demonstration, wouldn't we?
f: func [/local a b] [
a: ""
b: copy ""
for i 1 6 1 [
append a i append b i
]
print a print b
insert pick second :f 5 copy/part second second :f 6
]
The line in which 'b was created wasn't changed. Most dramatically, it
continues to be the exact same line you commented on as
>the creation of B
>is "dynamic" as opposed to A, where the creation is "static"
And you did announce that the dynamic creation accounts for the differences
we observe:
>So, the difference between A and B lies in the fact, that the creation of B
>is "dynamic" as opposed to A, where the creation is "static" and the notions
>of "global" vs. "local" are misleading in this case.
>
Since it is the "dynamic nature of the creation of b" which you hold
responsible for the behavior we observe, and since nothing about the
"dynamic nature" of b's "creation" was changed, we should be very
surprised, when we find that my extended function does the following:
>> f
123456
123456
== ""
>> f
123456123456
123456123456
== "123456"
>> f
123456123456123456
123456123456123456
== "123456123456"
>> f
123456123456123456123456
123456123456123456123456
== "123456123456123456"
Let me see an explanation that maintains that
>the notions
>of "global" vs. "local" are misleading in this case.
as you claim, while it manages to explain away the fact that while a and b
continue to be created in the exact same way the were before, which you
described as
>the creation of B
>is "dynamic" as opposed to A, where the creation is "static"
- no changes here. Yet now the function displays the exact same value for
'a that it displays for 'b.
We should also be surprised by the fact that the following variation of the
function:
f: func [/local a b] [
a: ""
b: copy a
for i 1 6 1 [
append a i append b i
]
print a print b
]
results in:
>> f
123456
123456
>> f
123456123456
123456123456
>> f
123456123456123456
123456123456123456
since here, also, b continues to be assigned as a reference to the result
of 'copy, which you describe as:
>when the interpreter encounters the expression:
>
>copy ""
>
>, which is a sign of dynamic data creation.
and
>the creation of B
>is "dynamic" as opposed to A, where the creation is "static"
Comments? Ideas? Opinions?
Elan
