Since PARSE is at heart a matching task, it seems there might be more accommodation when the input value is not a block... and you want to do some top level pattern matching. Consider something like this:
case [
integer? item [
print "Not a series, so, have to write handling code here"
]
text? item [
print "A series, but maybe we want to do something else"
]
block? item [
print "Okay finally we can use the parse we mean..."
uparse item [...rules...]
]
] else [
fail "Whatever"
]
When I see this I start thinking along these lines:
parse reduce [item] [
integer! (print "More convenient, perhaps...")
|
text! (print "Depends on the use case...")
|
subparse block! [
(print "Your rules here I guess...")
]
] ; raises definitional error on no match, handle w/EXCEPT etc. if needed
Now imagine that being something like PARSE-VALUE instead of PARSE REDUCE [ITEM]...but with additional cleverness.
One aspect of being better would be that if your input was calculated, you could still call it up with <input> ... although that wouldn't be available to the code in groups automatically:
>> parse-value 1 + 2 [integer! (print "int") | text! (print "text") || <input>]
int
== 3
>> parse-value "foo" [integer! (print "int") | text! (print "text") || <input>]
text
== "foo"
But you're no worse off than in a switch statement that doesn't have calculated input captured under a name. (Slightly better, in fact, since you have a means of calling up the calculated input.)
It's just a thought, because I've seen this pattern several times: "I have a decision tree but I can't start doing parsing until I have a series". This is just an idea about stretching all the matching and extraction logic that is going to be needed in PARSE anyway to apply to single values.
PARSE-VALUE or PARSE/VALUE
This strongly parallels the LOAD-VALUE vs. LOAD issue. It seemed to make more sense in that case to separate it out so LOAD was fully generic and unconcerned with the /VALUE aspect. This might or might not have the same rationale as to why PARSE shouldn't internally be concerned with the behavior.