R3-Alpha had an idea--carried forward by Red--of an arity-1 IF combinator.
red>> num: 1020
red>> parse [a a a] [if (even? num) some 'a]
== true
red>> parse [a a a] [if (odd? num) some 'a]
== false
As you see, if the expression you give it turns out to be "falsey" then it doesn't continue matching. It skips to the next alternate--if there is one.
red>> parse [a a a] [if (odd? num) (print "Boo") | some 'a]
== true ; didn't print the message
But That Doesn't Look Like an IF
But I always thought the arity-1 IF was a pretty alien thing that would confuse people. You might think there's a branch, but there's no "branch"... just continuing along with the variadic list of everything that follows until the next | or end of BLOCK!.
So I've renamed it "CONDITIONAL", with the abbreviation "COND"
>> num: 1020
>> parse [a a a] [cond (even? num) some 'a]
== a
>> parse [a a a] [cond (odd? num) some 'a]
** Error: PARSE BLOCK! combinator did not match input
I thought Ren-C's more generalized INLINE-based constructs made it superfluous (because you could embed any control construct into a GROUP! and synthesize a "veto" rule if you wanted to stop the parse). But I'm actually using COND more often than I thought.