> Traditional parsing techniques register semantic actions to production rules.
Are there any professional slop interpreters who can explain what this means?
vkazanov•12m ago
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.
jiggawatts•10m ago
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.
throwup238•24m ago
Are there any professional slop interpreters who can explain what this means?
vkazanov•12m ago
"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.
jiggawatts•10m ago
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.