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) |
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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.