Joined 5 months ago
One grammar I have been using to make a comparison is a function signature. I tried comparing with nom and chumsky: https://blog.arnedebo.com/posts/a-grammar-first-approach-to-...
These libraries have found ways to replace "unwrapping" code with combinators like separated_by or .ignore_then etc. but this still leaves a lot of code for result handling, in my opinon making the code harder to read and reason about, which is what I attempt to improve.
These are of course very subjective things, so another person might prefer the ways the other libraries do this.
When writing parsers you will often use multiple nested combinators. This means you have nested tuples. Getting the values out of these means "unwrapping" these tuples. Additionally you might not need all of the values in the sequence, some of them might only be for parsing whitespace. So when using the results of the parsers to construct values you have to ignore them. This can for example be done by "mapping" the resulting tuples and only leaving relevant fields. There are other approaches as well, for example chaining parsers with p1.then_ignore(p2) which only returns R(p1).
Maybe I could have chosen the words here a bit better, I hope this makes it more clear what I mean.
I have also tried making a side-by-side comparison of parsers for grammars being written using my library and others, maybe this can act as an example: https://blog.arnedebo.com/posts/a-grammar-first-approach-to-...
One disadvantage that I think parser combinators have, for example compared to parser generator libraries (where the parser is generated from a seperate grammar file), is that you have to add a lot of mapping / unwrapping code. In my opinion this makes the parsers harder to read.
As an attempt to improve this, I have been working on a parser combinator library in rust. It adds two extra combinators (capture and bind) which can store the results of parsers in buckets (bind) and use the values stored in these buckets later to construct results (capture). This allows you to eliminate the unwrapping / mapping code and seperate the grammar from the result contstruction.
If you have the time, I would really appreciate feedback on this!
You can find it here: https://github.com/ArneCode/marser
Feel free to ask me any questions or suggest improvements!
I am the author of marser, a parser-combinator library in rust.
I have tried outlining the reasons for writing this library in this blog post: https://blog.arnedebo.com/posts/a-grammar-first-approach-to-...
The main aim of the library is to make parsers readable and understandable by enabling users to write code that resembles formal grammars / ebnf (more on that in the blog post). It also has additional features like error recovery, custom error diagnostics and a TUI for debugging the parsers.
This is my first library, so I would really appreciate some feedback on design decisions / usability etc.
Disclaimer: I have used AI for parts of the documentation, for some of the macro code and things like the TUI viewer but the core parsing code has been written by me.
Would be nice to have a way to tell the scan that some parts are intentional, like #[allow(...)] in rust
