phplrt 4.0

PHP in a Grammar

A grammar on its own only answers "is this valid?". To get a value out of a parse - a number, an AST node, a configuration array - you attach PHP to a rule. That piece of PHP is called a reducer, and it runs when the rule matches.

This page is about writing one in a .pp3 file: where the code goes, what the compiler puts around it, and what happens to it when the parser is generated. What a reducer is handed and what it should return is Results and Reducers.

A Block of Code

Put it between -> and the rule body:

1Number -> { return (int) $children->value; }
2  : <T_DIGIT>
3  ;

Whatever it returns becomes the value of the rule. The code is ordinary PHP - loops, conditionals, whatever you need:

 1Name -> {
 2    $name = $children->value;
 3
 4    if (\str_starts_with($name, '$')) {
 5        return new \App\Ast\VariableNode($offset, \substr($name, 1));
 6    }
 7
 8    return new \App\Ast\ConstantNode($offset, $name);
 9}
10  : <T_NAME>
11  ;

Braces inside strings are safe - the block is read by a real PHP lexer, so "{" is a string, not the end of the block.

An empty block (-> {}) is the same as writing no reducer at all.

The Variables

Inside a code block, these are available:

Variable What it is
$children What the rule matched. This is the important one.
$ctx The full Context object
$token The last token the rule read, or null
$offset Where that token starts, in bytes
$source The source being parsed
$content The whole content of that source
$rule The id of the rule being reduced

All except $children and $ctx are shorthands the compiler expands for you - $offset becomes $ctx->token->offset, and so on. They are only declared if you use them, so there is no cost to the ones you do not.

What $children holds depends on what the rule matched - a token, an array of them, or whatever the reducers below it returned. See What $children Contains.

In Generated Code

When you generate a parser, reducers become real methods, named after the rule they belong to:

1private static function reduceNumber(\Phplrt\Parser\Context $ctx, mixed $children): mixed
2{
3    return (float) $children->value;
4}

Two practical consequences.

Your code appears verbatim in the generated file. It is debuggable and steppable, and a syntax error in a reducer is a syntax error in that file - so run the generator as part of your build, not at deploy time.

A grammar file has no use statements, so how a short class name resolves depends on where the reducer ends up - the global namespace when the grammar is read on the fly, the generated file's namespace when it is generated. The safe answer is to write class names fully qualified:

1// ✔ works either way
2Number -> { return new \App\Ast\NumberNode($offset, $children->value); }

If the fully qualified names make a big grammar unreadable, you can declare the imports on the generated file instead:

1new Compiler()
2    ->load(FileSource::createFromPathname(__DIR__ . '/grammar.pp3'))
3    ->generate()
4        ->withNamespaceName('App\Parser')
5        ->withClassImport('App\Ast\NumberNode')
6        ->save(__DIR__ . '/Parser.php');
Number -> { return new NumberNode($offset, $children->value); }

The trade-off: that grammar now only works when generated. Pick one approach per project rather than mixing them.