The article doesnt read like slop. And this is a very clear sentence to anybody who knows any amount of parser theory.

"Production rules" are rules in grammar descriptions for tools like yacc. "Semantic actions" correspond to pieces of code/logic executed whenever a given rule is fully parsed from input.

The blog reads like organic human text, not mechanical slop.

The terminology is baroque, but pretty standard in parsing circles.

Essentially, different parsing algorithms "run side effects" at different stages of the parsing algorithm application, which can make certain things easy or difficult depending on the timing.

E.g.: If parsing runs side effects before it has 100% decided on what rules have been applied, it may need to "back track" and undo side-effects. This can be very painful to code around, so a common solution is to build (only) a temporary abstract syntax tree (AST) in a pure functional manner, and later come back and process that instead of trying to handle every "do and undo" scenario during initial parsing.

Parsers that only ride side-effects when a decision is final allow very efficient compilers that directly "do the thing" instead of building temporary structures.

IIRC, Pascal was compiled this way, in a single pass.

I assume that they refer to what you do when you write a Yacc or Bison file or any other input file for a similar parser generator.

A Yacc file contains the grammar of the language to be parsed, but to each grammar rule you can attach a C function that will be invoked by the generated parser when matching that rule.

Executing the operation inside the semantic action only works for simple calculators. Otherwise you have the problem that the line of code may run multiple times even though it's only parsed once. Usually you make the semantic actions build an AST (a data structure holding the structure of the program, e.g. new BinaryExpression(left_ast, '+', right_ast)

Others here already answered your question. In the blogpost, the text that immediately follows already demonstrates the concept, then it contrasts to what's done in Pratt parsing (semantic actions to to terminals instead of non-terminals). Non-terminals is another way to refer to production rules. This difference is a pretty big deal so it's important to mention. The rest of the section goes on to explain the consequences of this difference. None of this is mentioned in other Pratt tutorials that I read before so I doubt a slop machine would write articles of Pratt parsing even mentioning this trait at all.

That is not slop btw

This is standard CS terminology - if you take a compiler course it'll be explained in the first couple lectures.

The ELI5 is that "semantic actions" are bits of code that a parser generator runs, and "production rules" are patterns that tell it when to run them.

I would usually think of a 'parser' as simply something that tells you how to produce the input given a set of production rules. There are no actions involved.

For a simple ambiguous arithmetical grammar, the output of a parser fed "1 + 2 * 3" might be something like "[Mul [Add 1 2] 3]", or "[Add 1 [Mul 2 3]]", or "1 2 3 Mul Add". The form of the representation doesn't matter; it's just an indication of the sequence of steps that gets you from 'nothing' to whatever input string was provided.

But there's not really a concept of 'actions' to go with parsing. Parsing tells you how some string was constructed, or how it might have been constructed.

[delayed]

Well, quoting from the Dragon Book, page 8:

---

The second phase of the compiler is syntax analysis or parsing. The parser uses the first components of the tokens produced by the lexical analyzer to create a tree-like intermediate representation that depicts the grammatical structure of the token stream. A typical representation is a syntax tree in which each interior node represents an operation and the children of the node represent the arguments of the operation. A syntax tree for the token stream (1.2) is shown as the output of the syntactic analyzer in Fig. 1.7.

This tree shows the order in which the operations in the assignment

    position = initial + rate * 60

are to be performed.

---

For context, token stream 1.2 is the sequence of lexer output "ID1 = ID2 + ID3 * 60" (7 tokens long), and Figure 1.7 shows that sequence being transformed by a parser into the tree "[= ID1 [+ ID2 [* ID3 60]]]".

Back to the textbook:

---

The subsequent phases of the compiler use the grammatical structure to help analyze the source program and generate the target program.

---

I'm struggling to see where this disagrees with my earlier comment in even the most minor detail.

I notice that the quote you provide comes from a later chapter, "A Simple Syntax-Directed Translator", and that there is no suggestion there that parsing involves semantic actions. Rather, semantic actions annotated on to a finished parse tree are presented as a tool for generating translations.

Had you moved on to the chapter section immediately following the one you quoted from -- the one titled "Parsing" (page 60) -- you might have seen that it opens by saying this:

Parsing is the process of determining how a string of terminals can be generated by a grammar.

[delayed]

> [I was] pointing out that even the Dragon Book talks about associating actions with parsing by attaching them to production rules for the parser.

But that's just a false claim. The book does no such thing. The book, in the quote you pulled, talks about attaching semantic actions to finished parser output. At that point, the parser has already completed its work. It will never do anything again. The actions will neither affect it nor be seen by it. It's kind of like saying that illustration is part of writing a novel because an artist inserts their work into the finished manuscript.

Did you not notice that your quote doesn't contain any form of the word "parse"?

In the diagram displayed in section 1.2 ("The Structure of a Compiler"), we see a statement processed in turn by a lexical analyzer, a syntax analyzer, a semantic analyzer, an intermediate code generator, a code optimizer, and finally a code generator.

The book informs us explicitly that a "syntax analyzer" and a "parser" are the same thing.

But those semantic actions are associated with the intermediate code generator two steps down the pipeline. They've got nothing to do with the parser.

for another perspective, raku lets you carry around reusable grammars, but each time you parse something with them you have the option to specify an actions class, the methods of which are invoked and passed the corresponding matches from the grammar (this lets you reuse the actual grammar matched against; sometimes you just want to typecheck cli arguments to main against a grammar and aren't actually going to use the match as anything other than an ornate boolean, but you might as well keep the actual grammar in sync between that nop/bool parser and another parser that actually builds something useful later).

so that's another community's vote for actions as something belonging to The Parser over and above the strict grammar by which that parsing is done.

At least in imperative languages, a parser generator can execute arbitrary code, including side effects. There's nothing stopping that code from simply returning a data structure; indeed, most productions will have semantic actions that just say "return new Mul($1, $2)". However, the ability to add imperative side effects is what allows things like keeping a comment counter for nested comments; keeping a symbol table in case the same token might be a keyword or variable; handling indent levels in newline-sensitive languages; and so on.

Even in declarative languages like Haskell, your parser combinators will usually operate in a state monad so you can do things like this. True context-free grammars are rare; many real programmer convenience features have some level of context sensitivity, which is usually handled more easily by side effects in the semantic actions than by generalizing to a context-sensitive parser.