At the top level, PARSE allows only a BLOCK! rule.
>> parse ["abc"] "abc" ** Script Error: parse does not allow #[datatype! text!] for its rules argument
But when a rule is being invoked by reference, you get the option of that reference not having to be a BLOCK!:
>> rule: "abc" >> parse ["abc"] [rule] == ["abc"]
Being able to break down your parse rules into named subexpressions is one of the huge advantages PARSE has over things like RegEx.
But there are questions raised about whether certain fetched contents from names should be matched as value, matched as rule, or considered errors.
As an example: What do you think this should do?
>> x: first [skip] == skip >> parse [skip skip] [some x] ???
There seem to be three possibilities for what [some x] does in this context:
This is what R3-Alpha does, and allowing "rule indirection"... e.g. if a word looked up to a word that was a rule, it could be used:
r3-alpha>> x: first [skip] == skip r3-alpha>> parse [skip skip] [some x] == true
On the surface, this has the appeal of generality and the substitution principle. It implies any term that could occur in the rules as source could be put behind a WORD!.
>> x: '(print "Hi!") == (print "Hi") >> parse "aa" [some ["a" x]] Hi! Hi! == "aa"
I am not a fan of this. It may be what you meant when it's something like a word or group, I think the more likely intent with a generic X would be that you were trying to match the content literally.
(And retriggering rules looked up via WORD! is very sketchy...especially if the rule takes arguments. Beyond being sketchy, it simply doesn't work in the UPARSE combinator model.)
Despite this being more likely what you meant, there's no need to guess. We have a new means of accomplishing this with the @-types that is much more general:
>> parse [skip skip] [some @x] == skip
This lets you fetch a value and match it literally. So BLOCK! is not matched as a rule either:
>> block: [some "a"] == [some "a"] >> parse [[some "a"] [some "a"]] [some @block] == [some "a"]
I feel a twinge of prescriptivism in saying that you either use the @xxx syntax at your reference sites or you form your subrules as proper blocks -or- inert values (strings and binaries).
So I think this is the option we should go with.