I tried out the concept of changing Rebol's historical behavior of splicing by default, to only splicing if you say /SPLICE. It incorporated the concept of modal parameters, so append [a b c] @[d e] would be a way of saying "splice".
And I didn't like it.
Here's an extraction of why, that was on another thread but I'm moving it here to make the useful part of that post more useful.
Consider this case from the tests...It's code that builds code with COLLECT and KEEP COMPOSE. I'd previously been pleased with tricks like how compose [(...): ...] could produce the SET- forms of the composed material (if there was one), and can even do better with automatic word conversion (e.g. why should compose [(unspaced ["meth" n]): ...] be an error just because there's no SET-TEXT! form of string, it could just be an unbound word):
keep compose [
(to word! unspaced ["meth-" n]): method [] (collect [
keep 'var-1
repeat i n - 1 [
keep compose [
+ (to word! unspaced ["var-" i + 1])
]
]
])
]
So I'm of course disappointed to imagine having to change those to either KEEP/SPLICE -or- KEEP @(...). The parentheses junk it up...when you're using a COMPOSE you really want to see the parentheses in the compose itself primarily:
keep @(compose [
(to word! unspaced ["meth-" n]): method [] (collect [
keep 'var-1
repeat i n - 1 [
keep @(compose [
+ (to word! unspaced ["var-" i + 1])
])
]
])
])
So that's depressing. KEEP/SPLICE isn't as bad here (KEEP/MANY? KEEP/MULTI? Whatever you call it):
keep/splice compose [
(to word! unspaced ["meth-" n]): method [] (collect [
keep 'var-1
repeat i n - 1 [
keep/splice compose [
+ (to word! unspaced ["var-" i + 1])
]
]
])
]
But is this a tradeoff to be concerned about?
It's tough to really think about all the damage past and present that implicit splicing has done.
Not to mention all the /ONLYs that are out there (plus the ones forgotten), when just looking at how one previously "slick" seeming example has gotten less palatable.
Is KEEP/SPLICE really so bad here? If it really gets on your nerves in a larger sample, why not define an emitter that does both the compose and the splice and use that?
collect [
emit: adapt :keep/splice [value: compose value]
emit [(1 + 2) (3 + 4)]
emit [(5 + 6) (7 + 8)]
]
== [3 7 11 15]
Or maybe whether KEEP splices is directed by the code block, in the same way as MAP-EACH...
>> collect [
keep compose [(1 + 2) (3 + 4)]
keep compose [(3 + 4) (5 + 6)]
]
== [[3 7] [11 15]]
>> collect @[
keep compose [(1 + 2) (3 + 4)]
keep compose [(3 + 4) (5 + 6)]
]
== [3 7 11 15]
Then if you know you have some blocks that aren't meant to be spliced, you put them in a block to protect them.
Big Picture Thought: Reliability Of Parts is the Key
My feeling is that Rebol plateaued because it gave some basic manipulation abilities that seemed to work well enough. But when people tried to do bigger things it let them down. You get a cool idea like wanting to write your own loop construct, but find suddenly RETURN didn't mean what it needed to.
So lamenting the fact that you have to say append/splice compose where once you could just say append compose is probably the wrong granularity to be looking at. Systemically the question is whether the system is versatile enough to be customized in notable ways. And one of those ways will be Redbol with splice by default and the old /ONLY behavior just as it was.
But on the good news side, the system does flex as intended to add features to be able to try them.