Re: [Q] Grammars and LL(1) Parsing

LLkParsing@aol.com
19 Oct 2000 14:30:19 -0400

          From comp.compilers

Related articles
[Q] Grammars and LL(1) Parsing calius@netvision.net.il (2000-10-15)
Re: [Q] Grammars and LL(1) Parsing Sid-Ahmed-Ali.TOUATI@inria.fr (Sid Ahmed Ali TOUATI) (2000-10-18)
Re: [Q] Grammars and LL(1) Parsing LLkParsing@aol.com (2000-10-19)
| List of all articles for this month |

From: LLkParsing@aol.com
Newsgroups: comp.compilers
Date: 19 Oct 2000 14:30:19 -0400
Organization: Deja.com - Before you buy.
References: 00-10-107
Keywords: books

> Specifically, LL(1) Grammers, LL(1) Parsing Tables and Ambigiouty.


"Crafting a Compiler with C" by Fischer & LeBlanc does have a nice
explanation of LL(1) parsing. However, it really is "as simple as that."


Resolving parse table conflicts is more difficult, but is not very well
covered in most books. In many cases, extending the grammar to LL(k)
does the job. For example, in the C language, when the parser sees an
open parenthesis, it cannot tell whether this starts a parenthesized
expression or a cast. Peeking ahead to the next input character
differentiates the two cases.


Sometimes a conflict is caused by a true ambiguity in the language. The
usual example is nested if-else clauses in C. LL(k) essentially has no
way to decide if the programmer wants the else to match the preceding
if, or an earlier one. The simple and logical disambiguating rule is to
always match the closest if.


Some ambiguities can only be resolved by parsing the particular input.
In C++, a function-style cast looks just like a declaration. The rule
here is that if it looks like a declaration, then it is a declaration.
Good language design generally avoids this type of conflict.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.