Rebol's extremely strange nature makes people wonder what they should or shouldn't be doing with it. When I tried writing basically my "first mezzanine" (COMBINE) long ago, I faced questions pretty much anyone writing such a primitive would...like Should a WORD! be treated casually as if it were an ANY-STRING!?
>> mode: 'depeche
>> combine/with ["a" mode "b"] space
== "a depeche b"
Back then, I didn't know if that should be an error or not. And if WORD! would be legal, should SET-WORD! too? Would it have a colon? Or was there a higher purpose for these things in the dialect, and should a variable holding one act the same as if one were literally present in the block?
Ren-C is on the path of thinking of "ANY-WORD!" as being strings is correct. Which led me to consider this piece of code from HELP:
for-each [a b] [
"!" "-ex"
"?" "-q"
"*" "-mul"
"+" "-plu"
"/" "-div"
"=" "-eq"
"<" "-lt"
">" "-gt"
"|" "-bar"
][
replace/all item a b
]
What it is doing is pretty simple. It is trying to convert a Rebol name to one that is readable/safe to use in a URL, so the help website URL doesn't have "weird" characters in it.
But if we're all on board with WORD! as working as a string, do you really need all those quotes? Couldn't you say:
for-each [a b] [
! -ex
? -q
* -mul
+ -plu
/ -div
= -eq
< -lt
> -gt
| -bar
][
replace/all item a b
]
You can do that, though it won't work for everything. e.g. : would not be a legal WORD!. And | is BAR!...like how _ is a BLANK!...one must wonder, if those will "stringify" to be how they look. Is this a good practice?
What I want us to be saying clearly now is YES: it's a good practice and you can count on writing code like this. I think it's foundational to what Rebol is about.
Though as a matter of taste, I actually think the following looks slightly better, because using different types creates a kind of delimiting:
for-each [a b] [
! "-ex"
? "-q"
* "-mul"
+ "-plu"
/ "-div"
= "-eq"
< "-lt"
> "-gt"
| "-bar"
][
replace/all item a b
]
But that's just me. YMMV.
When put together with the null change, this gives a reasoning to why print ["a" _ "b"] will actually print out a _ b, with the underscore. That seemed annoying before, because "who wants to actually see the underscore?" But now we know it's null's job to be invisible, and they're popping up in more places. So when you consider this example, you understand that blanks might arise in places where they were being used source level for their "underscore-ness"...not for their BLANK!-ness.