3 ms·
I think you're not using the word precedence properly. It seems as if you're trying to explicitly instruct a top-down parser. E.g., the precedence in these two
by tgv 2y ago
I think you're not using the word precedence properly. It seems as if you're trying to explicitly instruct a top-down parser.
E.g., the precedence in these two grammars (for simple arithmetic expressions) is identical
S -> F | S + F
F -> T | F * T
T -> 0 | 1 | 2 | ...
S -> F | F + S
F -> T | T * F
T -> 0 | 1 | 2 | ...
but one recurses on the left side, and the other on the right.
- mrkeen 2y ago> It seems as if you're trying to explicitly instruct a top-down parser. My mistake, that didn't even occur to me! I only ever use parser combinators so I just read grammars as if they were the code, and vice-versa. e.g. you could implement the grammar on the upper line as the code on the lower line: S -> F | F + S s = f <|> (f >> char '+' >> s) The two grammars you posted both 'look good' just by eyeballing them, neither needs 'fixing' (per the article title). They have identical precedence and identical don't-recurse-infinitely properties.
- tgv 2y agoA grammar is not the language. A language can be described by infinitely many grammars. That also goes for precedence. Parsing theory describes which algorithms can handle which grammars, and how efficiently they can do that. It allows you to ignore the details of parsing.