Currently SET accepts WORD! and SET-WORD!, allowing it to either establish the set quantities as candidates for local gathering or not.
I may be forgetting an existing GET-WORD! behavior, and correct me if I am wrong. But if there isn't one that's meaningful, might it be helpful if it could handle when the words named mention the target variables? Consider that this current behavior is deemed useful:
>> x: 'foo
== foo
>> y: 'bar
== bar
>> set x 10
== 10
>> print foo
10
>> set y 10
== 10
>> print bar
20
...so why not allow a GET-WORD! passed to SET if it's inside a block to do the same thing, instead of just mirroring what a non-GET-WORD! does? It suggests an evaluation step. I'd also think that if you put a parenthesized expression, then it could be used to define the target if the target came back as a word to store the value.
If the value was a series position and not a word, that could present an opportunity to say "set this position to the value". That's a bit edgier.
>> x: "Hello World"
>> set [(head x) (next x)] [#"J" #"o"]
>> print x
Jollo World
Just thinking out loud with that bit, probably makes it too mixed up functionally with CHANGE. I don't know if a variant that lets you do multiple changes in one operation is something that has a purpose as much as something that lets you do multiple sets does, due to the multiple return value applications. Being able to batch up more than one operation into one call should probably have a "purpose" to get into the core; SET has that purpose and it's not clear that CHANGE does vs writing something to do that yourself.
;--
;-- CURRENT BEHAVIOR
;--
>> x: 'foo
== foo
>> y: 'bar
== bar
>> set [:x :y] [10 20]
== [10 20]
>> print foo
** Script error: foo has no value
>> print bar
** Script error: bar has no value
;--
;-- DESIRED BEHAVIOR
;--
>> x: 'foo
== foo
>> y: 'bar
== bar
>> set [:x :y] [10 20]
== [10 20]
>> print foo
10
>> print bar
20
foo: 10
bar: 20
x: 'foo
y: 'bar
set reduce [x y] [10 20]
== [10 20]
>> probe foo
== 10
>> probe bar
== 20
Rebol is a combinatorial language. many low-level functions are meant to leverage each other without having to re-implement every possibility of the language each time.
Rebolbot commented on Mar 5, 2015:
Submitted by:BrianH
The current behavior is kind of the opposite:
>> a: 'b
== b
>> set [:c] [a]
== [a]
>> c
== b
Instead of getting the value of the variable, it gets the value of the value. Works with direct word values too. I don't know what it's meant for, but it certainly wasn't documented. I didn't discover it until we optimized the source of SET. It seems like a way to get values associated with words. Now that I think of it, this seems like it's ready-made for getting around our problem with words assigned values that can be awkward to write literally, such as true, false and none.
>> set [:c] [none]
== [none]
>> none? c
== true
Which behavior is more valuable? Given the problem we have with MOLD generating words like this in our damned code, I'm leaning towards documenting and promoting the existing behavior.
Rebolbot commented on Mar 5, 2015:
Submitted by:MarkI
Since there is currently no difference between set [:c] [:none] and set [c] [:none], we can repurpose the former, so as to enable both behaviours.
Rebolbot added the Type.wish on Jan 12, 2016
Ladislav commented on Feb 9, 2016:
I support BrianH's opinion and lean towards documenting and promoting the existing behaviour, however, the change to the semantics of the set [:c] [:none] is also possible, and I do not suppose it to cause any problems.
Submitted by: fork
Currently SET accepts WORD! and SET-WORD!, allowing it to either establish the set quantities as candidates for local gathering or not.
I may be forgetting an existing GET-WORD! behavior, and correct me if I am wrong. But if there isn't one that's meaningful, might it be helpful if it could handle when the words named mention the target variables? Consider that this current behavior is deemed useful:
...so why not allow a GET-WORD! passed to SET if it's inside a block to do the same thing, instead of just mirroring what a non-GET-WORD! does? It suggests an evaluation step. I'd also think that if you put a parenthesized expression, then it could be used to define the target if the target came back as a word to store the value.
If the value was a series position and not a word, that could present an opportunity to say "set this position to the value". That's a bit edgier.
Just thinking out loud with that bit, probably makes it too mixed up functionally with CHANGE. I don't know if a variant that lets you do multiple changes in one operation is something that has a purpose as much as something that lets you do multiple sets does, due to the multiple return value applications. Being able to batch up more than one operation into one call should probably have a "purpose" to get into the core; SET has that purpose and it's not clear that CHANGE does vs writing something to do that yourself.
Imported from: CureCode [ Version: r3 master Type: Wish Platform: All Category: Native Reproduce: Always Fixed-in:none ] Imported from: https://github.com/rebol/rebol-issues/issues/2184
Comments:
Submitted by: maxim
easily accomplished this way:
Rebol is a combinatorial language. many low-level functions are meant to leverage each other without having to re-implement every possibility of the language each time.
Submitted by: BrianH
The current behavior is kind of the opposite:
Instead of getting the value of the variable, it gets the value of the value. Works with direct word values too. I don't know what it's meant for, but it certainly wasn't documented. I didn't discover it until we optimized the source of SET. It seems like a way to get values associated with words. Now that I think of it, this seems like it's ready-made for getting around our problem with words assigned values that can be awkward to write literally, such as true, false and none.
Which behavior is more valuable? Given the problem we have with MOLD generating words like this in our damned code, I'm leaning towards documenting and promoting the existing behavior.
Submitted by: MarkI
Since there is currently no difference between set [:c] [:none] and set [c] [:none], we can repurpose the former, so as to enable both behaviours.
I support BrianH's opinion and lean towards documenting and promoting the existing behaviour, however, the change to the semantics of the
set [:c] [:none]
is also possible, and I do not suppose it to cause any problems.