Lexy: a Parser Combinator Library for C++17
Posted4 months agoActive4 months ago
github.comTechstory
calmmixed
Debate
60/100
Parser CombinatorsC++17Parsing Libraries
Key topics
Parser Combinators
C++17
Parsing Libraries
The HN community discusses Lexy, a C++17 parser combinator library, with comments ranging from praise for its performance to concerns about its limitations and potential improvements.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
4d
Peak period
8
84-96h
Avg / period
2.8
Comment distribution11 data points
Loading chart...
Based on 11 loaded comments
Key moments
- 01Story posted
Sep 10, 2025 at 10:05 AM EDT
4 months ago
Step 01 - 02First comment
Sep 13, 2025 at 11:34 PM EDT
4d after posting
Step 02 - 03Peak activity
8 comments in 84-96h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 15, 2025 at 11:04 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45197896Type: storyLast synced: 11/20/2025, 3:38:03 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
To be explicit: one of the "features" this advertises is equivalent to saying "if you stop compiling your code with `-Wall`, you don't have to deal with all those pesky warnings!"
You're still not being explicit. Are you referring to the error recovery? Do you disagree that this is useful in real world applications? A C++ parser with `-Wall` would do error recovery and keep going on syntax errors.
In my opinion, parser libraries/frameworks indeed are all mired by the usual suspects which make adoption painful:
* Must learn another grammar language which for some strange reason I suspect has to do with "tradition", must reside in _a file_ -- as opposed to just be expressed with code (i.e. `bin_expr = Concatenation(Ref('expr'), bin_op, Ref('expr'))`); if a BNF language _is_ used for grammar, it almost always is used with some non-standard syntax for helping resolve shift/reduce errors, etc -- which for me puts it into the same "this is not needed" category
* Defined by the kind of parser that is generated, so implying you have to know parser theory in order to know what languages you will never be able to parse with said library/framework; made even worse when some kludge is added with extensive documentation on how to get out of the predicament because "the parser cannot theoretically handle the grammar/language but it otherwise is really great because it uses ABC kind of parsing which is why we chose it" -- the impression it gives a person who knows parsing enough to know they need to construct a grammar and that the grammar may feature ambiguities, is that they have to learn more parser theory; when you learn more parser theory, you usually just implement your own parser unless you need to parse e.g. C++, admittedly; for case in point, see my remark on the "recursive descent parser" being used with Lexy
To be frank, I like the addition of yet another parser generator -- the more the merrier, because contrary to that one earlier statement, that "parsing is a solved problem", I think it is not -- the theory has substantial headway on the practice, meaning that in theory it is [a solved problem], but in practice it is not, in my experience.
Here's the use case:
expr := ...
rule1 := expr foo expr
rule2 := expr bar
When trying to match rule1 and failing, it is great to have the expr part of it already parsed and ready for trying out rule2.
This doesn't have to be done extremely well (see PEG/Packrat parsing for that) but even a little bit, maybe one term or something like that helps a lot.
Pressing rules are written in c++ directly, with templates.
Although if you have no experience in parsing, the learning curve could be a bit steep.