Choosing a parser library for a language

I want to create a really simple language that compiles to SPIRV. Today I had a look at various parser libraries.

The first libraries that came to mind were and I have to say combine looks really clean.

But then I found out that the author of combine also works on a language Interestingly he chose over his own parsing library. There is also and for parsor generators.

I have to say I don’t fully see the advantage of parser generators at all, they seem too magical. Is there something inherently wrong with parser combinator libraries for parsing a language? I could potentially see that it might be easier to make large scale changes to a parser generator.

Which library would you choose and why?


Not an answer to your question, but you might find the following paper interesting It uses nom but talks a bit about parser generators vs parser combinators in principle.

Thanks, I probably will also use nom.

@MaikKlein I recently worked on a parser for a scene description (for my renderer) and tested pest. So far so good …

This is why I like them, I write my grammar and I get AST, no coding involved. One of benefits is that library may improve with time in terms of speed or error messages, and I won’t have to do anything to get that, so +1 for lalrpop from me.
I am using it and had no problems with it, though I’d love to see ANTLR supporting Rust.

I’m currently using nom in a project that involves parsing programming language source code:

I’m quite happy with nom for now, the documentation could be better (and I’ll try to also work on it). If you want to help improve it join the discussion here:

Since I was just asking myself the same question, I looked around for articles on the topic. I can recommend this article on the differences between parser combinators and parser generators. It helped me a lot to make an informed decision.