3 ms·
Some limitations of this particular article: * it doesn't mention that operator-precedence (usually: Pratt) parsing is another alternative * it doesn't mentio
by o11c 3y ago
Some limitations of this particular article:
* it doesn't mention that operator-precedence (usually: Pratt) parsing is another alternative
* it doesn't mention that you don't have to evaluate the expression directly; it's perfectly possible to output an AST, RPN, or some kind of minimal bytecode.
* unless you do a bit of optimization, you can't reduce the number of "registers" needed à la Schneider. While generally less relevant for interpreters unless you do some careful platform-dependent design, interpreters can easily benefit from the one-register case.
* you're allowed to use an ahead-of-time LR machine generator, you don't have to encode its tables by hand (but for simple grammars it's not actually that hard to work out with comments).
* it doesn't sufficiently mention that you really want to work with IDs in a lot of cases; among other things this avoids further unary/binary problems (though I suppose synthesizing an extra argument also works).
- kybernetikos 3y agoI think your second point actually is covered: > Note that “applying” an operator can mean a couple of different things in this context. You could actually execute the operators, in which case the operands would be numerical values of all the terms and subexpressions; you could also build a syntax tree, in which case the operands would be subtrees. The algorithm works the same way in either case.
- Syzygies 3y agoAs for "you don't have to evaluate", from the article: > you could also build a syntax tree, in which case the operands would be subtrees.