Hi, I had a problem to find your post and respond to it (sorry).
just want to point out some errors made by you:
1) In Rebol A and B don't mean the same as you suggest: 'a and 'b, which is
misleading.
2) You are inferring: "In REBOL it is a property of literal strings that
they are global and
therefore persistent." - Interesting. The first part of the sentence is
wrong and second is (almost) right. Anyhow, I do like the word "persistent",
it's OK with me. To be exact, there are no persistent values
in Rebol, every value is only quasi-persistent, which means, that it can be
garbage-collected under some circumstances. Even the literal strings are
quasi-persistent, as can be seen here:
f: func [/local a] [
a: "I am "
append a "Jimbo" ; let's call the string Jimbito
print a
]
f
source f
f: func [] [] ; now Jimbito becomes unreferred
recycle ; now Jimbito doesn't exist for sure
3) "REBOL automatically establishes a reference to any literal string from
the global context. " - error (see e.g. the above code)
4) See the expression:
a:
copy "" ; let's call the preceding literal string Jambo
; let's call the result of copy Jumbo
I am sure that Jumbo was created the very moment copy did it (that means
dynamically) and is not the same as Jambo, which is "more persistent".
Through this I made sure that no
change to Jumbo (like e.g. Change A "x") can cause a change to Jambo. The
problem is, however, that
there is a lot of other possibilities how to change Jambo as you nicely
demonstrated in your example. Well, a SMC is a SMC (self-modifying code).
Ladislav
----- Reply separator -----
> 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
>
>
>
>
