Joshua Barretto

Try this: ```rs #[derive(Debug, Clone)] pub enum Val { Integer(i64), } #[derive(Debug, Clone)] pub enum Exp { Val(Val), Neg(Box), Mul(Box, Box), Div(Box, Box), } fn parse_order_bug_parser

Parsers are lazy when evaluating sections of input. `unary` will succeed on `5`, and then it'll pass control on to whatever follows. Unfortunately, in your original parser, *nothing* follows `unary`...

Thanks! A few thoughts: - Might I suggest `recursive_group` as a name? There's already precedence with the `group` combinator. - It feels like it should be possible to implement this...

> My only concern with that is that the `group` combinator parses each one of the items in order, where as the only order that matters for this combinator is...

Hmm. I do think this is a neat solution for the specific, limited-scope problem the original issue - but I can't help but feel like it doesn't go far enough...

I've implemented a version of my idea in #902, along with an example/test. It's extremely rough and not at all ready for merge, but hopefully there's enough meat on the...

It might be worth implementing a dedicated `fold` that has this behaviour though... Mind if I change the issue title and reopen?

This is a consequence of the way `recursive` works and, to some extent, the entire crate. In an ideal world, parsers would just implement `Parser` and then it would instead...

What would this integration look like? Chumsky already supports byte slices as inputs.

Yes, we could do with a `IterParser::chain` function that works as you describe. I'm going to rename the issue.