News for hackers. Stuff that matters.
Re:Parser Combinators by ArneCode on Sunday October 18, 2026 @10:02AM (#50141179)
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-...

Re:Parser Combinators by Jaxan on Sunday October 18, 2026 @10:56AM (#50141640)
I’ve always used parser combinaties in Haskell and I’ve never seen the things you describe. I guess in Haskell one always directly apply the parts to the function you want (ie an AST node constructor).
Re:Parser Combinators by black_knight on Sunday October 18, 2026 @11:08AM (#50141744)
We are spoiled in so many ways by Haskell!

Parser combinators alone makes monads (or really applicative functors) worth it. But then there are the all the other spectacular things we can do with monads!

Re:Parser Combinators by n_plus_1_acc on Sunday October 18, 2026 @01:59PM (#50143570)
This. The <$ and $> operators are very elegant for parsers.
Re:Parser Combinators by n_plus_1_acc on Sunday October 18, 2026 @01:59PM (#50143571)
This. The <$ and $> operators are very elegant for parsers.
Re:Parser Combinators by n_plus_1_acc on Sunday October 18, 2026 @01:59PM (#50143572)
This. The <$ and $> operators are very elegant for parsers.
Re:Parser Combinators by n_plus_1_acc on Sunday October 18, 2026 @01:59PM (#50143573)
This. The <$ and $> operators are very elegant for parsers.
Re:Parser Combinators by thedufer on Sunday October 18, 2026 @05:24PM (#50145630)
I think this is because Haskell allows hiding the tuples construction/unwrapping with do-notation. My primary interaction with parser combinators, in OCaml, uses a similar trick with binding operators. If you don't have some sort of syntactic sugar like that they do become a lot more unwieldy.
Re:Parser Combinators by kccqzy on Sunday October 18, 2026 @11:32AM (#50141966)
Doesn’t your language have native tuple destructuring syntax?

The ignore example is just p1 <* p2 in Haskell (that operator is in the standard library).