In the early days of tinkering with Rebol I was driven quite mad by the quite often useless-seeming combinatorics of when you would INSERT or APPEND data of various types together.
SPLICE! Helps Semantics
I think the right semantics of a SPLICE! is that APPENDing a splice like ~[x y z]~ to something, what you get out of that is equivalent to if you had done three separate appends of X, Y, and Z.
Though this still leaves us with questions like "what does it mean to APPEND something like a BLOCK! (or GROUP!, or FENCE!)... to a TEXT!"
I'm fairly comfortable with appending arbitrary lists to binaries or strings having no meaning. It often enough represents some kind of misunderstanding that I think we are on much firmer ground if we don't define it. That leaves dialect authors in a better position to define the meaning of these parts without prior expectations coming from the system, and makes their dialect code easier to maintain.
What Was Historical Redbol's Answer?
Because it didn't have SPLICE!, historical Rebol treated BLOCK! as a splice:
rebol2>> append "ab" [c d e]
== "abcde"
This looks sensible on the surface, until you go a little deeper and put blocks inside the block:
rebol2>> append "abc" [d [e [f g] h] i]
== "abcde f g hi"
This weirdness arises because while the outermost block is being treated as a "splice", it goes one by one on each item and "forms" it.
But let's look at some other behaviors...
WORD! APPENDING TO STRINGS SEEMS GOOD
rebol2>> append "abc" 'd
== "abcd"
I don't think I always saw this as being obviously good, as not putting a word through a string conversion may feel like a bit dodgy. But in the spirit of the language it now appears to be obviously good, where WORD!s are the light and universal currency of the language.
INTEGER! APPENDING TO STRINGS SEEMS OK TOO...
Integers do have kind of a lot of potential interpretations--and one might ask "why would we assume you wanted to append an integer in base 10".
TAG! Delimiters Aren't In The Tag
I've become fairly convinced of this, and so I think appending a TAG! to a string should not include the delimiters if it is allowed:
>> append "abc" <def>
== "abcdef"
Only Simple Sequences Should "FORM" (If Any)
There's been variance over versions of Redbols for what appending things like SET-WORD! would do to strings, or whether they'd form with or without their colons.
Anytime you see these kinds of variances in behavior, it suggests things are unclear. And the more unclear something is, the more likely it is that you should have to be implicitly involved:
>> append "abc" first [def:]
** An error here is probably (?) the best answer?
Now that "SET-WORD" has become a certain type of CHAIN!, this erroring behavior falls under a general rule of "CHAIN!, PATH!, TUPLE! require some kind of operation to stringify". Which seems to go along with "BLOCK!, GROUP!, FENCE! require some kind of operation to stringify".
But it does seem to be a bit oppressive at times:
>> append "abc" 1.2
** Is an error here better than "abc1.2"?
This made me wonder if the rule should be softened, to where a sequence that's built entirely out of things that are willing to string-convert should string convert? Though that starts to give strange results e.g. if TAG! doesn't append its delimiters:
>> append "abc" first [d.1.<foo>]
== "abcd.1.foo"
I'm conflicted over this.
General Principle: Conservatism, Default To Error
It seems like this is the sort of thing where being conservative and erroring...making people MOLD if they mean that...is probably for the best.