ANY [...] vs. PARSE's ANY ... Can We Have Consistency?

Development Naming
1

PARSE's ANY means "match this rule any number of times, including 0 times". 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 language this was:

if any [
    1 > 2
    3 > 4
][
    print "if 0 matching conditions was 'any', this would run"
]

One thought is that we don't really have a single word that means "zero or any number of". So why have a single word in PARSE? It could just be OPT SOME, which is unambiguous:

;-- any number of "a"s (including zero), followed by some "bs"
parse "bbb" [any "a" some "b"]

;-- optionally some "a"s, followed by some "b"s
parse "bbb" [opt some "a" some "b"]

I think it would be a reasonable argument for getting rid of ANY, even if there weren't a direct opposition in every day use coming from ANY [...]. One less thing to be confusing, one less thing to teach.

The true parallel application of ANY in PARSE would be to pick the first matching parse rule out of a list. But that's currently implicit: just having a BLOCK! with | between expressions turns it into PARSE's idea of an ANY:

 parse "abcbca" [some [any ["a" "bc"]]]

 parse "abcbca" [some ["a" | "bc"]]

I'm just trying to make the point that It just seems that it might be clearer if ANY wasn't an iterative construct.

So, thoughts...?

Has anyone ever thought that ANY in PARSE was kind of confusing? Could you get behind OPT SOME?

From some point of view, the idea that words have many different meanings is part of the point. It still seems like when you're putting things in the box together it might be nice if there was more consistency.

2

Currently parse keywords only apply to rules, not to other keywords. So there's no nesting, or keyword stack. I think this is important enough for readability to preserve if at all possible.

3

Not sure what you're referring to, but if it's opt some, that's not a rule in and of itself. OPT acts on the rule after it, allowing its failure to still count as success:

>> did parse "bbb" [opt some "a" some "b"]
== true

>> did parse "aaabbb" [opt some "a" some "b"]
== true

Works as expected, clears up the problems with ANY.