A unique and sometimes uncomfortable design point of Rebol dialects--best exemplified by PARSE--is that there is no decoration to distinguish keywords from non.
For instance, imagine the unlucky author of this routine:
filter: func [
data [block!] "data to search"
reject [any-value!] "item to filter out"
][
parse data [any [remove reject | skip]]
]
They thought it seemed fine, but didn't know that REJECT was a keyword. SKIP is also frequently used to hold an integer skip count.
When this kind of problem has come up in the past, I've thought that the right answer would be to take something like GET-WORD! to mean "use the real variable, not a keyword":
parse data [any [remove :reject | skip]]
But in PARSE's overloaded world, of course GET-WORD! is taken for "get parse position". Though I never particularly liked it, so I proposed mark pos instead of :pos.
Of course, this then meant anyone who had used a variable called MARK now ran afoul of the keywords. :-/
Should This Be Covered With A Single WORD! Operator?
If we consider keyword collisions to be an edge case, then taking a whole datatype for it might be excessive.
What if there were an operator which was a kind of escaping mechanism, that meant "don't treat this as a keyword?"
What comes to mind for me is a symbol, and it's one I've used for a connected purpose. It's the >-
parse data [any [remove >- reject | skip]]
By being symbolic and light, it doesn't disrupt too badly. It points at what it's talking about.
The concept would be that the default definition would just be a kind of pass-thru of its right hand side.
So sort of like func [x] [:x] but it would be like REEVAL, and be able to be invisible if its right hand were invisible:
>> (>- add 10 20)
== 30
>> (>- 304)
== 304
>> 1020 (>- comment "hi")
== 1020
Then the enfix form of this (SHOVE) could be ->-, which is not useless because it allows the right-hand side to be a PATH!.
With these in hand, dialects could promise that what's on the right of them wouldn't act as a keyword. That promise would be easy to keep if they were doing literal inspections of an evaluative feed and only running things they didn't recognize. Just don't do special handling for it, and the regular evaluation will happen.
PARSE Actually Has Another Avenue
I've become convinced that PARSE probably needs to use the @foo forms to mean "match this literally". Because the workarounds needed to get that today are too obtuse.
Notice that this won't work:
block: [some "a"]
parse [1 [some "a"] 3] [integer! block integer!]
This isn't helped by >- described above. The problem is a conflict in semantics, not a conflict in keywords.
But imagine if this did the intended thing:
block: [some "a"]
parse [1 [some "a"] 3] [integer! @block integer!]
That seems important to me, and it is connected systemically to the "as-is" notion this type is coming to be associated with.
While this is different, it would limit the cases you'd need to use >- with to those where you wanted a variable to act as a rule.
How Does This Compare with GET-WORD! for Subvert Keyword?
I still sort of feel like GET-WORD! makes more sense for PARSE to subvert keywords, and that MARK and SEEK are good enough for setting and getting the parse position (and much clearer).
parse data [any [remove :reject | skip]]
This sort of lines up with today's usage of GET-GROUP! for "splice this thing here so the parse feed sees it as if it had been written literally here".