Talk:LR parser

message: Two key notions used in the article "reduction" and "derivation" are not explained. Without these 
notions the article is useless for a beginner.   —Preceding unsigned comment added by 82.240.122.196 (talk) 19:08, 25 April 2009 (UTC)
replies: text: Yes, those things any user of parsers & generators cares about should be well-explained before diving into arcane details of LR(0) state machines, closures, and parse tables. The notions of reductions and bottom-up parsing are now described in a separate user-oriented article on Shift-reduce parsers.  I've added to the LR article a new intro that attempts cover the high-level concepts at a user level.  DBSand (talk) 05:45, 3 May 2012 (UTC)
replies: text: I believe this topic is best explained to beginners by starting with concrete examples of parse trees and shift/reduce parse steps for a nontrivial but small example, and then showing a concrete parse table with intuitive state names, and then discussing LR(1) conflicts.  And only then diving into the deep end of how states are defined and computed. DBSand (talk) 00:06, 9 May 2012 (UTC)
replies: text: What this Wikipedia needs is well-delimited material defining the reduction of sentential forms using productions of a formal grammar.  AHMartin (talk) 23:30, 10 March 2017 (UTC)
thread_title:  This article is useless for a beginner 

message: This article is one of the better explanations of LR parsing I have seen.  My only complaint is the dual use of the "*" character as (1) the current position in a in the LR(0) item, and (2) as the multiplication operator.  That leads to items like "E * * B" (an actual example from the text) which is confusing.  Perhaps we could just use a period?  --Doradus 22:35, 23 Aug 2003 (UTC)
replies: text: (Scratch that; apparently Konqueror renders · as an asterisk. --Doradus 23:16, 23 Aug 2003 (UTC)
thread_title:  Parse position indicator 

message: Looks like the "note on SLR and LALR" overlaps a bit with the section on conflicts.  Perhaps they could be combined. --Doradus 01:38, 26 Oct 2003 (UTC)
thread_title:  SLR and LALR overlap 

message: It's a really minor thing, but could we maybe change the grammars which use nonterminals "E" and "B" to use some other letters? They often look awfully similar on my screen. Marnanel 05:53, 4 Feb 2004 (UTC)
thread_title:  E and B nonterminals 

message: This is, indeed, a great explanation of the LR(0) algorithm. Nevertheless, I'd like to suggest a few changes that may make it better:
a) Change the term "begin state" to "start state", as it seems to be the most correct form to reference the, err, start state of a grammar.
b) the section "Conflicts in the constructed tables" needs some editing, as it seems. For example, it begins with the phrase "The automaton that is constructed is by the way it is constructed always a deterministic automaton", which, although correct, sounds confusing (at least to me). A better wording might be: "The steps presented so far always construct a deterministic automaton." or "The automaton contructed by looking for transitions between item sets will always be a deterministic one."
c) Besides (still in the section referred above), we find several references to the grammar not being LL(0). Because we're discussing LR(0), it looks like a typo. It would be better if an explanation of how the non-LL(0)-ness of the grammar afftects the LR(0) parser was given.
d) Finally -- and maybe this is just in my system, I guess that using • instead of · to represent the dot would make it more visble.
Great article. --Branco 13:39, 23 October 2005 (UTC)
replies: text: Go for it. --Doradus 22:57, 13 July 2007 (UTC)
thread_title:  Minor improvements to the article 

message: Although LR(0) item set construction is important bacause it is the basis for the SLR(1) parser construction algorithm as well as most LALR(1) construction algorithms, it should be pointed out that very few parsers are based on LR(0) itself.  Indeed, LALR(1) parsers such as those produced by Yacc and GNU bison seem to be the most commonly used LR(k)-based parsers.  Discussing LR(1) item set constuction would not only describe the LR(k) methodology when lookahead is a component of an item (as it always is except for the trivial case of k = 0), it would provide the basis for understanding the LALR(1) construction method and why an LR(1) grammar may not be LALR(1) or why an LALR(1) grammar may not be SLR(1).
It might also be pointed out that although a grammar might be LR(k) for some k > 1, there will always be LR(1), LALR(1), and SLR(1) grammars for the same language. --Raaronson 16:58, 27 December 2005 (UTC)
thread_title:  Discussion of LR(1) Construction Needed 

message: It might be worthwhile to have a section about what sort of grammars work best with LR parsers: yes, they can parse all LR grammars which is a strictly-defined set, but some work better than others.  E.g.:
  list ::= item ',' list
  list ::= item '.' 
is an LR(1) grammar that would need to shift the entire input onto the stack before reducing it, whereas:
  list ::= list-items '.'
  list-items ::= item
  list-items ::= list-items ',' item
is a grammar for the same language that allows the parser to reduce after each item.  I just added a note to left recursion that mentions this, although not in as much detail.  The same reference  is probably useful here. JulesH 08:06, 4 August 2006 (UTC)
thread_title:  Discussion of construction of grammars for LR parsers? 

message: I removed from section 1.2:
In practice the parser will usually try to recover from a syntax error by ignoring unexpected symbols and/or inserting missing symbols, and continue parsing, but this is outside the scope of this article.
This paragraph is like taken from a tutorial. Well, I imagine it's only because of the "outside of scope" thing. Whatever. --euyyn 22:14, 4 September 2006 (UTC)
replies: text: It's also not outside the scope of this article.  If someone wants to describe common techniques for error recovery, that's perfectly on-topic.  --Doradus 22:55, 13 July 2007 (UTC)
thread_title:  removed sentence 

message: These are what I found when searching on the Internet for my project on implementing a LR(1) yacc:
- Practical LR(k) Parser Construction . By David R. Tribble, 12/12/2004. This is a long and complete introduction, although many places are labeled as "+INCOMPLETE".
- The Honalee LR(k) Algorithm . By David R. Tribble, 4/27/2006. 
BTW, in "E → E + B", maybe B can be changed to T so it looks different from E. "Item" is called "Configuration" in some early papers in the 1970s.
-- oxc 10:04, 7 December 2006 (UTC)
replies: text: Yes, the Honalee algorithm is an LR(k) parsing algorithm I invented a while back. It creates LR parsing tables for what I called Merged LR (MLR) grammars, which lie somewhere between LALR and LR grammars in complexity. I have since discovered that it does not, however, handle all LR grammars. There are LR grammars that have mutually conflicting item sets that cannot be merged, but which my algorithm is not smart enough to detect. At some point when I have more time, I'd like to go back and complete the web pages. In the mean time, feel free to paraphrase portions of it for these WP articles. | David R. Tribble / Loadmaster (talk) 15:23, 10 February 2009 (UTC)
thread_title:  Web resource for LR(k) parser construction 

message: Prefaced the description of the stack machine with a remark about the alternative, functional, recursive ascent, view on LR parsing, and added a corresponding reference 81.5.0.80 18:45, 11 July 2007 (UTC)
thread_title:  Recursive ascent parsing 

message: I made a few corrections.  A parser does not deal with a grammar.  It reads computer languages.  It's the parser generator that "deals" with a grammar.  
About the "dangling else" problem ... A BNF grammar that contains the dangling else problem is ambiguous and NO parser can
handle it, unless the ambiguity is resolved !!!  An LR paser can and does handle the dangling else problem just fine, because
the ambiguity (or conflict) gets resolved at parser generation time by chosing to shift the "else" onto the parse stack instead of making a reduction before accepting the "else".  So, it is a misconception to say that an LR parser cannot handle the dangling else problem. 
About C++ and typedef ... A simple or pure LR parser cannot handle the context sensitive problems with C++ and the typedef in C.  However, a smart LR parser which uses the symbol table to classify <identifier>s as "typedef" or just <identifier> can successfully parse C++ and C typedef situations.   So, again, one should not generalize that LR parsers cannot handle C++, because in practice it is possible.  Theoretical computer scientists might disagree, but then changing definition of LR parser can decide the argument if you want to get mathematical.  I just don't like to put limitations on LR parsing, besides what other
techniques are you going to use -- recursive descent (what a nightmare)?
Paul B Mann  —Preceding undated comment added 00:36, 10 September 2009 (UTC)
thread_title:  Dangling else and typedef 

message: “LR parsing can be generalized as arbitrary context-free language parsing without a performance penalty, even for LR(k) grammars.”
What? This sentence does not make sense, I thought, LR(k) ⊂ CFL, and in the following sentences a performance-penalty is mentioned.
--Chricho (talk) 12:07, 11 September 2010 (UTC)
thread_title:  Arbitrary context-free-languages without penalty? 

message: The example parse for '1 + 1' is too trivial to give any insight into bottom-up versus top-down parses, or the handling of delimiters and non-infix operators, or necessary recursion, or the meaning of individual LR(0) states. DBSand (talk) 06:57, 3 May 2012 (UTC)
thread_title:  Example grammar and input are too small 

message: The example Action/Goto table should show the meaning of each state (ie its  unclosed item set), not just the state number.
The example parsing steps chart should have the stack (symbols & state#s) as left column, the decoded top state (ie its unclosed item set) as second column, the lookahead and unscanned input as third column, and parser action as fourth column.  The action column should show the actual grammar rule being applied, not just a rule number.  The 'output stream' column should be discarded; it is just the column of applied rules. 
DBSand (talk) 06:57, 3 May 2012 (UTC)
thread_title:  Tables and Charts 

message: This Prolog implementation belongs in some separate specialty article for Prolog fans, not here.  The backtracking pattern-matching mechanism underlying Prolog is much more complicated, slower, and opaque than LR's own deterministic, linear pattern matching methods.  Using Prolog to explain LR does not explain why LR is fast, or why LR grammars must be deterministic.  Other editors will not know how to correctly update the Prolog code if the article's main example changes.  And finally, Prolog is unfamiliar to most readers.  I doubt very much that 99% of readers of this article will get any understanding from a prolog description of the LR tables and parser algorithm.  
An imperative description of the parser's inner loop, in some widely understood language, with helpful names, could be helpful.  DBSand (talk) 06:57, 3 May 2012 (UTC)
thread_title:  Prolog? 

message: A combined version of the original article and a major rewrite is now online at the LR parser article's main public page.  The merging process is incomplete.  The intro, theory, and reference sections are similar to before.  All other content from the original article is now section "Additional Examples"; this section needs further adjustments.
The new section LR Tutorial is aimed for beginner readers, and to programmers who are users of LALR generators but are not concerned with the details of LR construction.  The section LR Generator Analysis is aimed to users who need understanding of grammar conflict complaints from their generator.  Both sections are built around a single example.  The example and grammar are bigger than that of the original article, so that 
1) the table has LR(0) conflicts as in most SLR(1) and LALR(1) grammars, and
2) some multi-symbol parse stack reductions occur before the end of input.
DBSand (talk) 20:30, 14 May 2012 (UTC)
replies: text: Thank you very much for understanding, I took a look at http://en.wikipedia.org/wiki/User:DBSand/LR_parser/Rewrite and it looks good. The main thing right now is to have all of the pieces of the puzzle in one place, I'm sure more parts will be added and the way the parts fit together will evolve, etc... Throwaway8493 (talk) 08:03, 16 May 2012 (UTC)
thread_title:  Major rewrite of article, May 14 2012 

message: In the section "Architecture of LR Parsers", now removed,
* LR theory parsers and most actual(table driven or generated-code) LR parsers are iterative, not a recursive program.
* The recursive ascent variant is a minor footnote, covered elsewhere in article, and should not lead this section.  And recursive ascent has same O(n) time and space efficiency as table driven, and is slower than explicit-stack non-table parsers.
* Proving of correctness is a dubious claim, since every yacc-like generator that accepts disambiguating rules makes parses that can't be proven correct.  Those parsers can only be demonstrated to work as expected by testing.  And no generator or parser skeleton has been proven correct.
* The mention of rightmost derivation is unnecessary jargon.
In the section "General Case", now removed,
* Calling the parser a state machine is misleading, unless you also go into theoretical jargon of PDAs and FSMs and their differences.
* An input buffer is unnecessary detail.
* The lookahead item is not mentioned.
* The goto table handles only some (nonterminal) moves to next state, not all moves.
* The grammar itself is usually omitted from the parser.
* The paragraph about rightmost derivations is better handled by prior discussions of bottom-up parses.
The diagram "Architecture of a table-based bottom-up parser" could be improved by showing the symbols & parse subtrees on the stack, not just the state numbers of the 1+1 example; and by showing the stack growing rightwards, not upwards; and by omitting the output line.
The metacode description of the LR parser loop should move upwards into the main tutorial section.
DBSand (talk) 22:50, 20 May 2012 (UTC)
thread_title:  Removed sections 

message: The use of "you" in the article is a violation of WP:TONE. We should remove all these "you"s. I propose we also remove the paragraph starting with "When using an LR parser within some larger program, ...". — Kennyluck (talk) 10:17, 5 January 2013 (UTC)
thread_title:  All occurences of "you" should be removed 

message: The third section of the article in its current form references a grammar as an example that is labeled explicitly as LR(0), but entirely isn't prefix-free. You can easily create "1 + 1" (E → E + B → B + B → 1 + 1) which is, of course, a prefix of "1 + 1 + 1" (E → E + B → E + B + B → B + B + B → 1 + 1 + 1). Yet that should not be possible since LR(0)-grammars are supposed to be prefix free.  
Or am I missing something here?
03:29, 19 January 2014 (UTC)
thread_title:  1 + 1 Example is not LR(0)! 

message: Currently the introduction ends with the sentences "LR is also better at error reporting. It detects syntax errors as early in the input stream as possible.", comparing LR to LL parsers. However, LL(1) parsers have the immediate error detection property. Strong LL(1) parsers only have the valid prefix property by default, but a small change to the algorithm can restore the IED property. The literature strongly implies that LL(k) has the IED property for all k, though I haven't found anywhere that states that outright. I think the statement should be removed, especially in light of the fact that the LL parser page only shows a pure LL(1) parser, which is likely to result in anyone reading both pages to think that the example parser has worse error detection properties than an LR parser, which is not correct. Klkblake (talk) 11:05, 24 February 2016 (UTC)
thread_title:  Incorrect/misleading statement about error reporting 

message: According to the linked articles, CYK algorithm#lead, Earley parser#lead, and GLR parser#Advantages, they all have O(n3) worst case complexity. So they can't need exponential time. Conversely, an algorithm that does need exponential time due to bad guesses doesn't deserve any of the threee algorithm names. - Jochen Burghardt (talk) 13:51, 1 April 2016 (UTC)
thread_title:  Worst case complexity of other parsers 

message: Some registered user might want to further explain - or define somewhere, that whenever the article talks about 'symbols', tokens and not necessarily single chars are meant. This might confuse some beginners. --2A02:8070:9288:6B00:6515:51E4:6551:5F5A (talk) 22:14, 27 February 2017 (UTC)
replies: text: I just wikified "symbol".  I wish there was either a cleanly delimited subsection (or a separate article) for the definition used in formal language theory.  But the correct definition is in the formal symbol page.  AHMartin (talk) 23:23, 10 March 2017 (UTC)
thread_title:  Symbols and tokens 

message: Hello fellow Wikipedians,
I have just modified one external link on LR parser. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20120205044802/http://www.cs.uky.edu/~lewis/essays/compilers/bu-parse.html to http://www.cs.uky.edu/~lewis/essays/compilers/bu-parse.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 15:12, 14 December 2017 (UTC)
thread_title:  External links modified 

message: The article immediately begins talking about `Product` and `Sum` productions without ever having defined the grammar whose sentences we are parsing. This makes it extremely confusing to follow the diagrams and explanation of the algorithm. It would be useful to precisely and clearly state the grammar that is being parsed at the outset.  — Preceding unsigned comment added by 173.177.218.122 (talk) 13:58, 11 March 2022 (UTC)
thread_title:  Explicitly show production rules