Name for rule to count how many times a PARSE rule matches?

Development Naming
1

There are cases where you want to know how many of a certain match there are.

Here's an example:

 uparse "<<<stuff>>>" [
     (n: 0)
     some ["<" (n: n + 1)]
     x: between here n ">"
 ]

Here I'm just trying to match the number of > on the right to how many < were on the left.

(Note: I still think this INTEGER! abstracting of rules is confusing to read. Is a REPEAT/LOOP keyword missing that would help? I've written about this, please register an opinion.)

This Feels Like It Needs A (Value-Bearing) Rule

Maybe call it TALLY ?

 uparse "<<<stuff>>>" [
     n: tally "<"
     x: between here n ">"
 ]

I'm reluctant to call it COUNT since that's used so often as a variable name / noun. But TALLY seems like fair game.

For now, it's checked in as TALLY for UPARSE

But the main thing to focus on here is just how much killer leverage we get when parse rules can fit into this extensible framework. And my major point I raised about synthesizing values that are not restricted to the type of the input.

2

So oddly enough, TALLY without paying attention to the result can be used as the replacement for historical instances of ANY or WHILE.

>> uparse "aaaccc" [some "a" tally "b" tally "c"]
== 3

>> uparse "aaaccc" [some "a" tally "b" some "c" tally "d"]
== 0

"Count the number of times this matches" along with ignoring the count is pretty lightweight, and perhaps some would consider it idiomatic for opt some

opt some
tally    ; three fewer characters, same as WHILE

I don't care for the tradeoff myself...but...it's worth pointing out that many result-bearing constructs have their results ignored.

But I certainly would prefer seeing people embracing this idiom to having a single-arity WHILE in PARSE!

1 Like
3

So I've never used this unusual suggestion of taking advantage of the zero-times-match.

But I'm wondering: are we limiting TALLY's applications by not allowing it to ever fail?

If you want a non-matching TALLY to be zero, that's now easy enough, since integers are literal:

[tally rule | 0]

And if you want NULL in the zero case, you could then say:

opt tally rule

Or you could elide it in the case where it doesn't match:

maybe tally rule

But you don't have these choices when TALLY will never fail.

Still...it's a little hard for me to say it won't consider a count of 0. I can think of a lot of scenarios where that is what you want, and having to write [tally rule | 0] for it feels awkward.