Most LALR parser generators (Yacc, Bison, Lemon) run your semantic actions during parsing, as each rule reduces, bottom-up.
That means at the time a rule's action runs, you don't yet know what its parent looks like. This pushes a lot of grammars toward hand-built AST classes and a separate walking pass whenever you need to look ahead into siblings or defer a decision until more context is available.
On the other hand, Yantra always builds the whole AST first, then walks it top-down in a separate pass, calling your semantic actions as it goes. A parent rule's action can run before its children are visited.
A single grammar can define more than one walker. For example, one that emits C++, another that emits Java, from the same parse. The AST and the walker classes are both generated for you.
A small example (full version, with compile commands, in the README):
start := expr;
expr := expr(a) PLUS expr(b)
%{
std::cout << "Adding" << std::endl;
%}
expr := NUMBER(N)
%{
std::cout << "Number: " << N.text << std::endl;
%}
NUMBER := "\d+";
PLUS := "\+";
WS := "\s+"!;
Adding
Number: 1
Adding
Number: 2
Number: 3
Some other things about it: integrated lexer with mode support (for things like nested comments), an optional amalgamated single-file output mode with a generated main(), C++23, MIT licensed.
It's young (0.5.1, pre-1.0) and single-maintainer, so treat it as early. I'd rather know what breaks than have it look more finished than it is.
Known gaps are listed at https://github.com/TantrixAuto/yantra/blob/main/docs/known_l...
Repo: https://github.com/TantrixAuto/yantra
Feedback and questions are all welcome. I'll be around.