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)