Can ANY, ALL, SOME have consistent meanings?


These words are used in multiple places and don’t always mean parallel things.

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.

Not the highest priority thing to worry about, but definitely worth thinking about, so here are a few thoughts:

ALL […] vs. CASE/ALL

ALL is a short-circuit construct. The first time it sees a falsey thing, it stops.

>> all [(probe 1) (probe 2 false) (probe 3)]
;-- null

But CASE/ALL takes away CASE’s natural “ALL-like” short circuiting. The /ALL makes it evaluate every condition, potentially running branches even after it has seen falsey conditions:

>> case/all [true [probe 1] false [probe 2] true [probe 3]]
== 3

Ren-C chose to make CASE/ALL return the evaluation of the branch associated with the last truthy condition. (Rebol2 and Red just return false if the last condition was falsey.) That aside, both of them evaluate “all of the cases”.

Could we have a word for something that wasn’t short-circuit, yet evaluated “all” of the conditions…and just returned the last truthy one or NULL?

ANY […] vs. PARSE’s ANY

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"]]

But you don’t want to have to say that any time you are making an alternate rule. 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?
  • Is there any name for an ANY-or-ALL-like thing which would evaluate all its conditions and return the last truthy result, else NULL? Could it have a catchy name to fill in CASE/XXX instead of CASE/ALL?


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.


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.