Talk:Operator-precedence parser

I've been implementing a parser based on the pseudo-code in this page, and I believe that the greater-or-equal (>=) test in the outer loop is incorrect. A strict greater-than (>) seems to work for me, but perhaps there should also an associativity test as per the inner loop. (First time contrib, apologies if this is in the wrong place or something.) Anthony —Preceding unsigned comment added by 118.68.30.163 (talk) 14:50, 13 March 2009 (UTC)

I rewrote the parenthesis-insertion code to present the essence of the algorithm with less distracting C-machination (eliminated a couple of tables & some peculiar end-cases, open-coded a loop) -- and to make lines shorter, and to make gcc -Wall compile it without complaint. I'll note here that it doesn't do anything about getting operator associativity right. In particular, using the usual rules, a^b^c should come out to a^(b^c) while a-b-c should be (a-b)-c. The present program adequately parenthesizes neither. Tom Duff 19:20, 23 August 2006 (UTC)

Thanks for the cleanup, Tom, though in my defence I don't think the original Fortran code handled associativity either :-) I must admit I've never tried to work out how to implement associativity properly with this quick hack, since it's not code I'ld ever use in a real program anyway. Might be a fun exercise one quiet evening though.

Anyway, back to the current text: "To show that one grammar is operator precedence, first it should be operator grammar. Operator precedence grammar is the only grammar which can construct the parse tree even though the given grammar is ambiguous." - am I the only person having trouble parsing that sentence? If I knew what the author was trying to say I might rewrite it in English... 129.113.28.125 19:53, 24 September 2007 (UTC) (Graham)

Hi Tom, if you're talking about the C code that implements the FORTRAN I approach, I think it's vital that the flaws with the C code are pointed out. I've altered your code to support parenthesis; perhaps you could take a look. I don't know how FORTRAN I handled it or the other remaining problems. Do you? -- Ralph Corderoy (talk) 10:37, 3 December 2009 (UTC)

While I'm here, it would be a good idea for some motivated person to rewrite the pseudo-code for the railway-siding algorithm in C or something. Tom Duff 19:28, 23 August 2006 (UTC)

This is the first time I've seen an operator precedence parser explained with no stack and precedence table. The elegence of such implementations is irresistable. While i'm not about to argue with any fact in the original article, I think it warrants a shout-out. Antinice 12:12, 18 April 2007 (UTC)

I believe there is an error in the pseudocode. However, I'm not confident enough in my knowledge to change it. Shouldn't the last line in the inner while loop, lhs := the result of applying op with operands lhs and rhs, actually be part of the outer while loop? If not, ignore, but someone please review it sometime. 71.98.94.127 (talk) 02:40, 20 February 2008 (UTC)

Hi. I think, the Precedence-Climbing-Algorithm should be also included in this article. It is a fast and flexible, fully capable operator-precedence-algorithm which is less complex than the shunting-yard-algo and much faster and more flexible than the classic solution. The article, which the wikipedia-article links to, handles the precedence-climbing-algo: (http://www.engr.mun.ca/~theo/Misc/exp_parsing.htm) If nobody answers, i will add it to the article. 80.254.190.93 (talk) 08:59, 25 November 2008 (UTC)

Gang, this page is kind of a mess. Precedence climbing is much more powerful than operator precedence parsing. For example, operator precedence parsing cannot deal with operators with different precedences. He cannot deal with multiple non-terminals in a row whereas precedents climbing can. Also it should give credit to Hanson from 1980s that had an earlier implementation (lcc portable compiler guy). this page should be purely about operator precedence parsing and then we should have a different page on precedence climbing. Note: ANTLR v4 which I hope to complete soon automatically converts left recursive expression rules to precedence climbing style rules. — Preceding unsigned comment added by Parrt (talk • contribs) 00:10, 6 June 2012 (UTC)

The posted algorithm doesn't correctly handle low-precedence unary operators

The current pseudocode algorithm in the article doesn't correctly handle low-precedence unary operators. For example, "-x^2" is parsed as (-x)^2 instead of -(x^2), which is probably what would be intended. More generally, let "&" be an arbitrary prefix unary operator, and "#" be a binary operator with higher precedence than "&". Then "&x # y" should be parsed as &(x#y) but the posted algorithm parses it as (&x)#y.

Furthermore, suppose "$" is a unary postfix operator with higher precedence than "&". Then "&x$" should be parsed as &(x$) but the algorithm parses it as (&x)$, which is wrong.

Now I'm sure this problem must have been already solved in the field (or in research), but I don't know any references to a correct precedence-climbing algorithm that correctly processes unary prefix and postfix operators. In any case, though, readers should be aware that the current version of the algorithm does not handle the above cases correctly.—Tetracube (talk) 01:19, 8 October 2012 (UTC)