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.
[–] thaumasiotes 4 days ago
[–] Jtsummers 4 days ago
I'll appeal to authority here and quote from the Dragon Book:
>> Program fragments embedded within production bodies are called semantic actions.
In CS, particularly around compilers, it's an old concept.
[–] thaumasiotes 4 days ago
--- begin quote ---
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
--- end quote ---
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:
--- resume quote ---
The subsequent phases of the compiler use the grammatical structure to help analyze the source program and generate the target program.
--- end quote ---
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.
[–] Jtsummers 4 days ago
I was specifically responding to your earlier statement:
>> But there's not really a concept of 'actions' to go with parsing.
And pointing out that even the Dragon Book talks about associating actions with parsing by attaching them to production rules for the parser. You don't seem to accept the literal text of the book, and that's not something I can understand. But that's your choice.
[–] thaumasiotes 4 days ago
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"; the diagram is Figure 1.6 and also Figure 1.7), 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.
[–] nostrademons 4 days ago
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.
[–] nagaiaida 4 days ago
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.
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 "AddExpr(1, MulExpr(2, 3))", or "1 2 3 Mul Add", or "1. Start with 1; 2. Add 2; 3. Multiply by 3", or (more likely in practice) in-memory data structures corresponding to one of those. 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. What you do with that information is up to you.
In the example above, the parser's interest in a MulExpr is that it can produce a string containing the token '*'. The fact that mathematically two times three equals six doesn't come up.