Home   Archive   Permalink



'change' and position element - bug?

Why, when specifying an element in the change block, does not change the entire element, but only part of it?
    
>> a: ["abc" "def"]
== ["abc" "def"]
>> change first a "X"
== "bc"
>> ? a
A is a block of value: ["Xbc" "def"]
>> change a "Y"
== ["def"]
>> ? a
A is a block of value: ["Y" "def"]
    
Is it supposed to be like this or is it a "bug"?

posted by:   Sergey_Vl     5-Jul-2022/2:44:54-7:00



Looks fine to me. You're not providing more data to change.

posted by:   Kaj     5-Jul-2022/3:27:02-7:00



I will try to explain differently
    
>> a: ["abc" "def"]
>> b: "X"
>> print rejoin [type? first a " " type? b]
string string
    
Now change STRING to STRING
    
>> change first a b
== "bc"
>> ? a
A is a block of value: ["Xbc" "def"]
    
The line was not replaced but was written OVER
If we do not specify "first", then the string is changed to the string
    
>> change a b
== ["def"]
>> ? a
A is a block of value: ["X" "def"]
    
Same with other elements.
>> change second a b
== "ef"
>> ? a
A is a block of value: ["X" "Xef"]
    
Why are the lines SUPERIMPOSED on each other with an indication of the position, and REPLACED without an indication?
    
P.S. The same behavior is in R3 and in Red, so I don’t understand something, but what?

posted by:   Sergey_Vl     6-Jul-2022/3:53:12-7:00



In "Data Management Apps with Rebol" (http://re-bol.com/data-management-apps-with-rebol.html)
    
Nik say:
...
change third names "Phil"
poke names 3 "Joe"             ; same operation as line above
...
    
but
    
>> names: ["John" "Joe" "Bill" "Bob" "Dave"]
>> change third names "Joe"
>> ? names
NAMES is a block of value: ["John" "Joe" "Joel" "Bob" "Dave"]
>> poke names 3 "Lu"
>> ? names
NAMES is a block of value: ["John" "Joe" "Lu" "Bob" "Dave"]
    
From the point of view of logic, it should be the same, but the result is different. Why?

posted by:   Sergey_Vl     6-Jul-2022/5:50:25-7:00



Try
change next a b
to get the effect you want.
    
When you PICK an item from series A, with FIRST or SECOND, you're no longer working on series A, but on the string series C you picked from block A.

posted by:   Kaj     6-Jul-2022/8:48:53-7:00



Thank you! Probably understood:
"next" chaning index in series and return blok!
"first" retun value element - string!
    
>> type? first names
== string!
>> type? next names
== block!
    
while in the "change" function it works with series! port!, and we give it string! and she, without reporting an error, incorrectly processes it
    
>> a: "abc"
== "abc"
>> b: "X"
== "X"
>> change a b
== "bc"
>> ? a
A is a string of value: "Xbc"
    
Then this is a function bug or its undocumented feature, that it allows the type string!

posted by:   Sergey_Vl     6-Jul-2022/17:22:59-7:00



or in Rebol "string!" this is a series "char!"

posted by:   Sergey_Vl     6-Jul-2022/17:38:37-7:00



Yes, STRING! is a SERIES! of CHAR!
    
CHANGE is fully intended to work on STRING!, as on any SERIES!. This is a fundamental REBOL concept. Both BLOCK! and STRING! are members of the type class SERIES!.

posted by:   Kaj     10-Jul-2022/19:40:29-7:00



Functions such as NEXT do not change the index of a SERIES!, they actually produce a new reference to the SERIES! with a different index.
    
Note that Meta uses FIRST-OF, SECOND-OF, etcera, and AT-HEAD, AT-TAIL, etcera, to make it clearer whether you are positioning in a series or picking an element from it.
    
(Strictly, NEXT would have to be AT-NEXT, but I chose for consistency with BACK, because they form a pair.)
    
Meta also allows handling series directly, without the overhead of a reference. This is usually handled transparently, without the programmer needing to notice.

posted by:   Kaj     10-Jul-2022/19:54:54-7:00



Thank you.
I need to understand more about SERIES! and other Rebol fundamentals.

posted by:   Sergey_Vl     11-Jul-2022/7:39:32-7:00



Name:


Message:


Type the reverse of this captcha text: "? e u r t"



Home