ArneCode

I think parser generators and parser combinators both have their advantages and disadvantages. For example with parser combinators you can use the already existing tools of the language. If you want the specific advantages of parser combinators, this could be a reason for not wanting to mix this.

In this case yes, but I would argue this is because the roll grammar is a relatively simple grammar, you have no nesting of different combinators etc. (I have used it in the README because it is simple to understand). The winnow code also using seperated_pair to ignore the "d" value, which is also adding some logic to retain only the count and sides result.

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 combining two parsers, for example in a sequence like pSeq in this website, you need to think about what to do with their return values. One approach is to put all return values in a tuple. So lets say we are combining parsers p1,p2,..., p_n in a sequence, then the return value of the parser created by pSeq(p1,p2,...,p_n) is (R(p1), R(p2), ..., R(p_n)) if R(p) is the return value of parser p.

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-...

I really like the animations, makes it intuitive to understand what is happening!

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

for context, you can find a HN discussion about the library here: https://news.ycombinator.com/item?id=48475144

Hi everyone! I am the author of marser [1], a parser-combinator library for rust. This tool can be used to see what the marser code of a certain grammar could look like, to help users explore how to use marser.

Feel free to ask me any questions or suggest improvements!

[1] https://github.com/ArneCode/marser

I use it because their pro plan is free for students

they propably have a lot of training data from their users, which might be useful for SpaceX which has a lot of compute

Hello everyone!

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.

Works for me

Interesting!

Would be nice to have a way to tell the scan that some parts are intentional, like #[allow(...)] in rust

I remember being able to have unlimited Claude opus queries on the free student plan, they must have had to change something to not loose too much koney

Ok, that's cool

Ok, you made me laugh :)

I think that most Amish were never used to technology though?

I think there are costs beyond having to sacrifice writing code yourself. When prototyping yourself you learn a lot about the problem, see what design decisions lead to what tradeofs. While you write code your brain is always running in the background, giving you thoughts about how things could break, where the structure could be simplified, where the code could be extended. I feel this is lost or at least reduced a lot when an LLM writes code because you have a lot less contact with the software.

I think it is unlikely that people will act to completely abolish technology once they are used to it in their everyday lives.