Joshua Barretto
Joshua Barretto
It's certainly true that the vast majority of chumsky combinators don't require the allocator. However, this isn't true of: - The `Rich` error type (severity: low, `Rich` is just a...
Thanks for reporting this! I'll try to get a chance to look at this soon, although my usual schedule has been interrupted due to becoming a dad - so if...
Simply put: I'm not very confident that it's had enough people using it and exploring its pros and cons to be 100% sure of the API. I'd very much welcome...
Yes, I encountered this exact issue and it's the motivating factor for #889, which effectively makes Send+Sync a requirement for recursive/boxed parsers. I would prefer if this were an opt-in...
Context in #933
Thanks! I think adding a new variant to `RichPattern` is fine also, and might be worth it for the ability to disambiguate at a type level (we don't want end...
Apologies, GitHub swallowed the notification for this. I think the only change needed is to add `#[non_exhaustive]` to the `RichPattern` enum.
Thanks for your contribution! My reason for being a little bit reticent is that the return type of parser function often needs to be fully-qualified for more complex cases, and...
The unary parser will always succeed when it sees the first character (5), because it is a valid unary expression. You're probably looking to write a precedence climbing parser, in...
The problem you have here is that your input is not *just* a product: `5` is, by itself, a perfectly valid `unary` too. So the parser sees that, decides it's...