separated_foldl and separated_foldr

[RiscInside]

Reading through documentation for winnow combinators, I can't help but wonder why separated_foldl1 and separated_foldr1 are a thing, but separated_foldl and separated_foldr are not.

I am writing a simple parser for basic expression language. At a certain point, I wanted to add good error reporting to see what winnow can do in that regard. To improve error messages, I wanted to add occasional cuts (this is needed to prevent backtracking from jumping to less relevant alternatives). Specifically, I wanted to add a cut for RHS of binary operator expressions.

I am using separated_foldl1 for parsing, but it does not leave me the opportunity to change parser used for the first element.

separated_foldl1(factor, token("*"),|lhs, _, rhs| Expr::new_binary(BinOp::Mul, lhs, rhs))

This is what I think it should look like

separated_foldl(factor, cut_err(factor), token("*"),|lhs, _, rhs| Expr::new_binary(BinOp::Mul, lhs, rhs))

So, to sum up, I think having separated_foldl and separated_foldr combinators could be useful. They can be reimplemented outside of winnow, but that's not a great solution IMO - separated_foldl1 is quite big and separated_foldl wouldn't be any smaller. On the other hand, I believe it wouldn't take much code at all to add those to winnow, as most of the code from existing versions could be reused (and separated_foldl1/separated_foldr1 could then just call into a new version).

[epage]

To clarify, you are not wanting

• separated_foldl(range, parser, sep, fn) (what the lack of 1 suffix means within winnow)
• separated_foldl(parser, sep, fn) where the parser can be applied 0 or more times (what the lack of suffix means in nom and what winnow would call separated_foldl0)

Instead you are looking for separated_foldl(first_parser, rest_parser, sep, fn) so you can backtrack in first_parser and cut to top in rest_parser, right?
One challenge is what to name this (since the suggested name already has a meaning in our API).
Maybe this is just because its new but this also feels a bit awkward / too-specialized to me. I wonder if there is an alternative generalization but so far I haven't come up with one.
Probably the first step for this would be to fork these to test out the idea in your parser, see how it works out, and see how needed it is by others, and then "graduate" it into winnow.

btw besides forking the combinators, a workaround for this would be (peek(factor), separated_foldl1(cut_err(factor), token("*"), fn)). That does incur a performance hit of running factor twice.

[RiscInside]

To clarify, you are not wanting

• separated_foldl(range, parser, sep, fn) (what the lack of 1 suffix means within winnow)
• separated_foldl(parser, sep, fn) where the parser can be applied 0 or more times (what the lack of suffix means in nom and what winnow would call separated_foldl0)

Yes, that's correct. I assumed that separated_foldl1 was called that after foldl1 function in Haskell that, unlike foldl that has a parameter for initial value of the accumulator, also takes one element before folding. I will try to think of a better name for winnow, but right now I don't have any good ideas either.

[epage]

I have only a superficial functional background :). Any naming either came from somewhere else or was inferred from how I saw other names used. In this case, I believe the difference with traditional foldl is that that takes an initial value while an initial parser is a dramatically different situation.