Historical Rebol PARSE's ANY means "match this rule any number of times, including 0 times". So it's effectively an iterative construct.
In the past I've griped about the use of the word. If PARSE were a fruit stand the conversation might go like:
me: "Do you have any apples?"
parse: "Yes."
me: "Can I buy an apple?"
parse: "No."
me: "I'm not @gchiu...so why not?"
parse: "Because I have zero apples."
me: "Why didn't you didn't tell me you didn't have any?"
parse: "Because I do. I just don't have some."
What bothered me was how much in direct contradiction with ANY's use in the regular language this was:
if any [
1 > 2
3 > 4
][
print "if 0 matching conditions was 'any', this would run"
]
Add to that the fact that ANY isn't iterative, it just means "pick the first thing that matches from this set", and the semantics feel quite inconsistent.
Freeing Up ANY Would Allow A More Fitting Use
The true parallel application of ANY in UPARSE would be to pick the first matching parse rule out of a list. e.g. these would be equivalent:
parse "abcbca" [some [any ["a" "bc"]]]
parse "abcbca" [some ["a" | "bc"]]
@BlackATTR points out that this might make it easier when generating alternate rules, since you wouldn't have to worry about sticking in the |
during generation. It's a pain to worry about putting (N - 1) vertical bars between (N) items to match from a set... but this way lists of items to match from could just be used as-is.
(UPDATE: This has been implemented, and is very slick!)
Are There Better Words?
Looking to other languages for inspiration...in at least one Haskell text combinator set, it also uses some to mean one or more match, but picks many for zero or more matches.
Doesn't make a whole lot of sense. But because we're sort of dealing in a gray area of learned behavior here, I wonder if the benefit of going with MANY to avoid the inconsistency with ANY in regular code is enough to prefer it?
Or we could switch around and keep ANY for PARSE, but change the language so that ANY is prefix OR with ALL as prefix AND.
and [thing1, thing2] then [...]
or [thing1, thing2] then [...]
But I'm not a fan of that. I like the direction of AND and OR as weird infix operations right now...so I think we should stick with that. I've even been considering that x and y should be allowed so long as Y is not a function with arguments; it can short circuit across the word if it quotes it.