pest VS pom

Nice work. Out of curiosity, did you consider using pest (https://pest.rs/) to help build your parser? Or is it too much for what you are doing?

And some related parser tools: - https://github.com/kevinmehall/rust-peg - https://github.com/pest-parser/pest - https://github.com/lalrpop/lalrpop

I had recently completed the first year of my Computer Science class at school and will begin my second year soon. My schools' class forces the use of Java programming language, and I absolutely hated it. So, over the course of a little less than a month, I wrote my own programming language, in Rust (objectively best programming language), using pest, to be as similar to Rust as possible, but compiling to Java.

I second pest.rs. Using it is fairly intuitive and there's also a live playground on their website which is great for quickly developing and testing your AST (abstract syntax tree) parser for whatever language you're implementing.

This is where you'll run into trouble. People who write parsing-related Rust crates generally write things like pest that expect their syntax to be defined completely at compile time so the parser can be run through the compiler's optimizers for best performance.

Give https://pest.rs a try.

For now I have used pest to generate an AST that borrows from the given input. But if I can manage to make the parser generic over the return type it may be worth a refactoring.

pom

Maybe a parser combinator library is not what you want? One alternative might be writing an expression parser without a library at all: https://matklad.github.io/2020/04/13/simple-but-powerful-pratt-parsing.html (Depending on the grammar you are parsing a Pratt parser might actually be a good fit!) A PEG might also be more suitable for your use case, like pom.

I saw the performance comparison against pom, pom is unfortunately quite slow compared to an handwritten parser as it boxes most (all?) parsers so you may want to compare against a handwritten parser, or at least something in the same ballpark (for reference, combine's json benchmark on the same data is about 6x faster with "good errors", when optimized to work on &str-like input it is about 12x faster, nom or a hand written parser may be another 10-20% faster than that, if I remember correctly.) From a brief skim of the code, I don't see anything that would hinder it from at least closing that gap however.

Everyone on this sub seems to be using nom. In my experience I find pom to be intuitive and have to write less code. Maybe it's just me I'm having a hard time understanding nom which has a lot of function calls rather than less.If you compare both the json examples on both projects, the pom example is a lot clearer to read and a lot shorter.