Re: LL(1) parser table

Kaarthik <kaarthik@cisco.com>
13 Jan 2002 22:56:28 -0500

          From comp.compilers
Related articles
LL(1) parser table hyperarien@yahoo.com (2002-01-05)
Re: LL(1) parser table gsc@zip.com.au (Sean Case) (2002-01-07)
Re: LL(1) parser table dr_feriozi@prodigy.net (SLK Parsing) (2002-01-13)
Re: LL(1) parser table kaarthik@cisco.com (Kaarthik) (2002-01-13)
Re: LL(1) parser table kaarthik@cisco.com (Kaarthik) (2002-01-13)
Re: LL(1) parser table hyperarien@yahoo.com (2002-01-14)
| List of all articles for this month |
From: Kaarthik <kaarthik@cisco.com>
Newsgroups: comp.compilers
Date: 13 Jan 2002 22:56:28 -0500
Organization: cisco
References: 02-01-026
Keywords: parse, LL(1)
Posted-Date: 13 Jan 2002 22:56:28 EST

Precisely! This grammar is not a LL1 grammar. LL1 parsers have a
limitation, they're dumb in that they won't be able to handle such
collissions. (canonical) LR parsers are better off, 'cos they are
stateful, they remember the amount of processing that has been done so
far. This helps in choosing which branch to take in a similar (first or
follow, which rule to follow) kind of collissions. That's the reason why
tools like 'yacc' are LR. Not that LR parsers are totally collission
free (you might still get a reduce-reduce conflict, but for this
grammar, you may not), but they offer a formalism which makes it
possible to remember what amount of parsing is complete. Constructing a
LR parser is not a very difficult thing to do either, when you can
construct a LL(1) parser, this is just a bit more work that's all.




> Does this means the above grammar is not suitable for LL1 parsing?
>
> thanks in advance...

Post a followup to this message

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