| Type | Wish | Status | submitted | Date | 3-Nov-2014 17:36 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Native | Submitted by | fork |
| Platform | All | Severity | minor | Priority | normal |
| Summary | SET [:X :Y] [FOO BAR] equivalent to SET X FOO SET Y BAR |
|---|---|
| Description |
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. |
| Example code |
;-- ;-- 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 |
| Assigned to | n/a | Fixed in | - | Last Update | 5-Mar-2015 22:44 |
|---|
| Comments | |
|---|---|
|
(0004541)
maxim 5-Nov-2014 12:15 |
easily accomplished this way:
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. |
|
(0004593)
BrianH 5-Mar-2015 16:01 |
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. |
|
(0004596)
MarkI 5-Mar-2015 22:44 |
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. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 5-Mar-2015 22:44 | MarkI | Comment : 0004596 | Added | - |
| 5-Mar-2015 16:08 | BrianH | Comment : 0004593 | Modified | - |
| 5-Mar-2015 16:01 | BrianH | Comment : 0004593 | Added | - |
| 5-Nov-2014 12:15 | maxim | Comment : 0004541 | Modified | - |
| 5-Nov-2014 12:15 | maxim | Comment : 0004541 | Added | - |
| 3-Nov-2014 22:05 | fork | Description | Modified | - |
| 3-Nov-2014 19:06 | fork | Description | Modified | - |
| 3-Nov-2014 17:37 | Fork | Description | Modified | - |
| 3-Nov-2014 17:37 | Fork | Description | Modified | - |
| 3-Nov-2014 17:37 | Fork | Code | Modified | - |
| 3-Nov-2014 17:36 | Fork | Ticket | Added | - |