Add fold_count parser equivalent for count

[nickelc]

No description provided.

[cenodis]

This is already possible with fold_many_m_n. I dont think adding a completely new parser just for m == n is worth it.

[cenodis]

There needs to be a check inside this loop to see if the child parser actually consumed any input. The child parser not consuming input inside a loop is an error condition. See fold_many_m_n for an example.

[nickelc]

This is already possible with fold_many_m_n. I dont think adding a completely new parser just for m == n is worth it.

You could say the same about count.

[cenodis]

You could say the same about count.

There are some convenience parsers that allow you to avoid using fold_* (such as many_*). But I think thats a bit different from adding another fold_* parser.

My current problems with this:

• We already have 3 fold_* functions and adding another one for a use case thats already covered by another (and is trivial to use for such cases) is just unnecessary .
• Its name doesnt fit in with the other functions of the fold_* family. If anything it should be called fold_many_m.

[Stargateur]

At least name it fold_many_n

[cenodis]

At least name it fold_many_n

I think you mean fold_many_m. The n is the second parameter which doesnt exist here.

[Stargateur]

At least name it fold_many_n

I think you mean fold_many_m. The n is the second parameter which doesn't exist here.

in math, n come first then you use m, plus n is the max in fold_many_m_n.

[cenodis]

in math, n come first then you use m, .

I dont think thats a set rule. n is often used to denote a number of something. However in math one also often uses x or even a. It usually comes down to preference and context. To my knowledge there is no strictly enforced order of variable names, there are some conventions but those are not mandatory and only apply in their respective context.
In this case I would prefer to stay in line with the other function names and make it fold_many_m. Alternatively we could drop it altogether and just make it fold_many, with the possibility to later expand the parameter to also take ranges as proposed in #1393.

plus n is the max in fold_many_m_n

Irrelevant. This parser is about the case of m == n.

[Stargateur]

Irrelevant. This parser is about the case of m == n.

how irrelevant, that stupid, obviously this is for max only so take n is totally relevant.

Alternatively we could drop it altogether and just make it fold_many

yes why not

[cenodis]

how irrelevant, that stupid, obviously this is for max only so take n is totally relevant.

The only obvious thing is that n and m are the same in this parser. So they can be used interchangeably. Whether you use the minimum or the maximum is irrelevant if they are the same.

[Stargateur]

how irrelevant, that stupid, obviously this is for max only so take n is totally relevant.

The only obvious thing is that n and m are the same in this parser. So they can be used interchangeably. Whether you use the minimum or the maximum is irrelevant if they are the same.

I will repeat so, no that different you don't understand. if you take m this would mean only minimum, so take_many_m would be read as "take at least m" cause m IS the minimum in fold_many_m_n, n is more logical ( n come before m), match the max from already exist function and is often used as "the number n".

[cenodis]

This case is also handled by #1402 which in my opinion is a much more elegant solution compared to adding yet another specialized parser.

[Xiretza]

This should be solved by #1608, which allows fold(n, parser, init, fold).