Talk:LL parser

message: Is LL(*) equivalent to any CFG?98.169.86.44 (talk) 03:58, 10 April 2012 (UTC)
thread_title:  Is LL(*) == CFG? 

message: ::(Topic heading added for clarity.) yoyo (talk) 17:12, 30 April 2009 (UTC)
replies: text: The necessary correction was made before today. yoyo (talk) 17:12, 30 April 2009 (UTC)
thread_title:  Correction for "rightmost derivation" 

message: ::(Topic heading added for clarity.) yoyo (talk) 17:12, 30 April 2009 (UTC)
replies: text: Interesting question, but doesn't relate to actual (present) content of this article. yoyo (talk) 17:12, 30 April 2009 (UTC)
thread_title:  LL1+ parser 

message: Fi(w) is introduced, but Fi(A) - is not. What is the difference between them?
The passage "add Fi(wi) to Fi(wi)" is not clear for me.
I'd like to see more detailed and corrected description of the algorithm.
there should be an example -- as usually in those math related topics the description suffers from the lack of comprehensible language (what is it with mathematicians and computer scientist that makes them unable to speak other than in some gibberish? are the afraid common people will see, there's no magic?). i cam here because my book uses incomprehensible lingo, only to see wikipedia does, too.  —Preceding unsigned comment added by 217.84.33.129 (talk) 11:34, 16 June 2008 (UTC)
replies: text: The section Constructing an LL(k) parsing table is horrendously-difficult for a non-specialist to follow. As a pure mathematician by training, let me tell you that even mathematicians can't read this kind of notation well, if the symbols used are unmotivated and undefined - as they are here. Therefore, I will try to find a way to explain all this more clearly; but it will take some time and effort.yoyo (talk) 16:51, 30 April 2009 (UTC)
thread_title:  Algorithm of constructing parser table requires clarification, imo 

message: I think this needs a reference (to the "widely believed" part -- not to the PCCTS paper).  My understanding is that it was known long before 1990 that LL(k) parsers have exponential worst-case complexity, and this is still true.  We have also known for a very, very long time that many O(2^n) algorithms "sometimes" run in less-than-worst-case-time.
That said, I don't disupte that PCCTS and ANTLR are cool... but the article makse it sound like the world suddenly woke up and abandoned LR parsing in 1990, which is nowhere close to the truth, especially with the new, efficient implementations of GLR parsers that have come out in the last few years.
-----------------------------------------------------
OrangUtanUK: The following is my understanding, and may be complete rubbish. :o)
My key reference books - the Dragon Book for historical stuff, and Niklaus Wirth's "Compiler Construction" (aka "Compilerbau") - state that for LR(1) grammars you need a "shift-reduce" compiler, and that for LL(1) grammars you need a "recursive descent" compiler. The former recognises patterns as they emerge (ooh, that's an identifier, ooh, an equals, ooh, a numeric constant, aha, that's an assignment statement), whereas the latter works by prediction (if it starts with an identifier, it must be an assignment; now we expect an equals - yes, got it; now we expect an expression - call subroutine 'expression()'). Hence bottom-up or top-down parsing.
I was confused about the relative advantages of each until I read "high level languages and their compilers" by Des Watson. An RD compiler with an LL(1) grammar is O(n), very efficient, but quite demanding on the grammar designer. An SR compiler with an LR(1) grammar is O(n^3), less efficient, but capable of dealing with some very wild grammars, like those of COBOL or Java. Some languages can't easily be converted into an LL(1) grammar, so they end up as either LR(1) (hopefully) or as LL(k>1) (O(>n)). The thing about using tables is a generalisation, I think. There are some compilers that break the usual rule.
--------
I think your understanding is incorrect.  LR(1) grammars are also parseable in O(n) time; see: Knuth, D. (1965) "On the translation of languages from left to right." Information and Control, 8, 607--639.  LR languages are strictly more powerful: every LL(1) grammar is LR(1).  The converse is not true: grammars containing left recursion may be LR(1) but not LL(1).
In short, LR(1) parsers are strictly more powerful, but more difficult to write.  That's why parser-generators for LR(1) and related classes, are popular.
I think you might be confusing LR(1) with "generalized LR" or "GLR".  This algorithm can parse any context free grammar in worst-case O(n^3), but is vastly more powerful than either LR(1) or LL(1) -- in fact, you can reduce any instance of binary matrix multiplication to an instance of context-free (and hence GLR) parsing, so we'll unlikely to ever find an algorithm that runs faster than the fastest matrix-multiplication algorithm.
Megacz 18:15, 22 May 2006 (UTC)
thread_title:  "Widely Believed" 

message: "Figure 1" has been removed because it was unsourced, but the text still refers to it. It needs replacing. Hairy Dude 11:20, 11 February 2007 (UTC)
replies: text: There is presently no reference to "Figure 1", so there is no dangling reference in the article. However, it is still possible that a suitable diagram might improve the article. Yet I couldn't say what kind of diagram would be most suitable here. Perhaps the explanation of the parser procedure would be clearer with a well-crafted animation of the example. Thoughts, anyone? yoyo (talk) 17:20, 30 April 2009 (UTC)
thread_title:  Need replacement diagram 

message: There are several mentions of LL(*) in the article, but nowhere a definition or explanation. No wonder some people think computing and maths is black magic! ;-)
Could someone please supply a comprehensible definition of LL(*)? (Not me - I'm in the dark too.) Thanks! yoyo (talk) 16:56, 30 April 2009 (UTC)
replies: text: Practically the only comprehensive (and pretty comprehensible) description of this is chapter 11 of The Definitive ANTLR Reference. Essentially it describes grammars for which any given production can be parsed by using a DFA to look ahead to decide which alternative to follow. There is no finite limit on the number of tokens the DFA can look ahead, but the lookahead languages for each alternative of a production have to be disjoint and regular (if I understand correctly). --David-Sarah Hopwood (talk) 05:11, 1 June 2009 (UTC)

text: Definition added. Someone please check that I've got it right. --David-Sarah Hopwood ⚥ (talk) 00:20, 11 August 2009 (UTC)
thread_title:  LL(*) is undefined 

message: Can an LL(1) grammar be constructed for each and every context-free language, or are "LL(1) languages" a subclass on its own? --95.35.202.174 (talk) 08:15, 4 July 2009 (UTC)
replies: text: No, LL(1) languages are a strict subset of context-free languages (as are LL(k) languages for each k). See Rosenkrantz and Stearns, Properties of deterministic top-down grammars, Information and Control 17:226–256, 1970  (the answer to your question is stated in the paper's abstract). --David-Sarah Hopwood ⚥ (talk) 02:22, 11 August 2009 (UTC)
replies: text:  Thanks, David-Sarah. I've added the answer to this question to the article's introduction. Danielx (talk) 23:56, 11 May 2010 (UTC)
thread_title:  Does each [[context-free language]] have a corresponding LL(1) grammar? 

message: Although this article is rather good, it only mentions how to use a table-based LL parser to do nothing more than verify if a set of tokens belongs to a certain grammar.  It would be great if the article went a bit further than that and mentioned how to use a table-based LL parser to act on the grammar, either to build a abstract syntax tree or even how to extract information from a given language. -- Mecanismo | Talk 17:25, 27 March 2010 (UTC)
thread_title:  using table LL parsers to build a AST 

message: In the algorithm of construction Fi() set, there is "add Fi(wi) to Fi(Ai)" both in the beginning of the 2nd step and in the 3rd step. If I get it right, they are about the same thing (which needs to be done only once), so the one of them should be removed. Roman Cheplyaka (talk) 11:16, 31 March 2010 (UTC)
thread_title:  Probable mistake in [[LL_parser#Constructing_an_LL.281.29_parsing_table]] 

message: Shouldn't the definition for LL(1) FIRST/FIRST conflict be:
If the first set for two different productions of the same non-terminal overlap?  —Preceding unsigned comment added by 128.32.35.64 (talk) 01:52, 8 March 2011 (UTC)
replies: text: I agree. The rule     "* FIRST/FIRST conflict: The FIRST sets of two different non-terminals intersect;" is completely wrong. For the example grammar: S → F, S → ( S + F ),  F → a; we would get a conflict because FIRST(S) = {'(', 'a'} and FIRST(F) = {'a'} so they would overlap resulting in a LL1 conflict. Metalbeppi (talk) 20:21, 10 May 2011 (UTC)
thread_title:  LL(1) conflict 

message: A section should be added that gives more info on the parsing power of LL parsers.
How does LL(k) compare to LR(0)? LR(1)?
What is the power of LL(*)?
83.226.178.77 (talk) 21:47, 7 January 2012 (UTC)
thread_title:  Please clarify the power of LL compared to LR 

message: I wonder if the def. of Follow(A) as given in the section on Conflicts correct.  What if there is no production such that a non-terminal follows A?  If there is a production C -> zAb, where b is a terminal, then shouldn't b be included in Follow(A)?  Anyway, I haven't thought about this so much.  Maybe it's already correct.  — Preceding unsigned comment added by Vkantabu (talk • contribs) 20:19, 18 October 2012 (UTC)
thread_title:  Is the second def. of Follow correct? 

message: In the second paragraph:
 "LL parsers can only parse languages that have LL(k) grammars without ε-rules. "
I don't think is correct.  Later in this article, in the subsection "Left factoring", there is an  example of transforming grammars to better fit LL parsers - the outcome is this gammar:
 S -> 'b' E | E
 E -> 'a' | ε
which has an epsilon rule.
Was it meant "LL(0) parsers can only parse languages that have LL(k) grammars without ε-rules." maybe?  Not sure...
Effbiae (talk) 03:17, 5 May 2015 (UTC)
thread_title:  no epsilon rules? 

message: According the scientific community (http://richard.myweb.cs.uwindsor.ca/PUBLICATIONS/PADL_08.pdf), the worst case scenario for any LL parser is O(n^4).
However I cannot find any example, nor can I think of any, grammar that reproduces n^4 results for LL(1) parsing.
The example grammars given in the papers (S -> ‘s’ S S | S -> ‘s’ S | .. ) do not seem to hold.  This is because all the rules start with 's', and therefore any non-s is immediately rejected.  
Furthermore, if an 's' *is* found, parsing does not evaluate the less complex alternatives.  It will always match the first rule, 's' S S.  It will recursively loop through just that rule , and successfully find all the s's until the very last few characters.  Processing never evaluates the S of 's' S until the last two characters.
I've walked through this on paper.  The time seems linear.  Is LL(1) grammar somehow a special case?  Or have I missed something?
— Preceding unsigned comment added by Jktejik (talk • contribs) 04:36, 15 February 2018 (UTC)
thread_title:  is there an example of n^4 grammar for LL(1)? 

message: Am I right in thinking that \mathrm{LL}(*) = \bigcup_{k\in\mathbb{N}}\mathrm{LL}(k)? Hairy Dude (talk) 18:05, 11 May 2019 (UTC)
replies: text: I guess, \supseteq is easy to obtain, but \subseteq does not hold, since there may be a language L in LL(*) where the length of the "following tokens" (whatever that is supposed to mean in the lead) needed for parsing decisions may grow arbitrary long. This L couldn't be member of any class LL(k), and hence not of their union. - Jochen Burghardt (talk) 19:54, 12 May 2019 (UTC)
thread_title:  LL(*) 

message: In the section about constructing an LL(1) parser table, the set notation for step 2 is ambiguous. Set difference and union have equal precedence. Unlike arithmetic, set theory does not define a "left-" or "right associative" rule, so parentheses are always necessary.
: Different authors of set theory books may have different precedence conventions; however, if in doubt, parantheses should always be used. - Jochen Burghardt (talk) 07:39, 28 August 2020 (UTC)
thread_title:  Set difference and union have equal operator precedence, needs parentheses 

message: (Copied from User talk:Jochen Burghardt#LL parser C# code sample)
Jochen, I believe I 'reasonably addresses some aspect of those concerns' that the code sample is too complex.
As opposed to the C++ code, the C# is about entirely readable as proper English.
Instead of programming constructs like switch statements, the lookup table is a verbatim copy of that table from the text and the rules and symbols are strings and characters and readily recognizable.
In the C++ code otoh there are needles everywhere such as the stupid enum prefixes, shouting uppercase identifiers, abbreviations like ss, pointers with stars and whatnot, etc etc etc. For non-programmers especially, that C++ is a huge hurdle because you have to parse every little few characters carefully.
The reason I wrote this C# is that the text surrounding the C++ sample and the C++ code itself are not as digestible as you apparently assume and I believe my C# has none of these problems. 2A02:A45E:1569:1:30EB:ABCC:7DF4:2369 (talk) 15:38, 15 January 2023 (UTC)
replies: text: I think we should not have 3 parser implementations in the article. From your above post, it seems you'd agree with that, but suggest to remove the C++ implementation. In that case, I leave the decision to editors who know both C# and C++. I only know some C++, but no C#, so I'd be biased. The C# implementation can be found at https://en.wikipedia.org/w/index.php?title=LL_parser&oldid=1133716445 . - Jochen Burghardt (talk) 16:52, 15 January 2023 (UTC)
thread_title: C# code sample