Re: C and LL (1)

dr_feriozi@prodigy.net
4 Nov 2001 23:52:47 -0500

          From comp.compilers

Related articles
C and LL (1) pjbp@netc.pt (Pedro Pereira) (2001-10-23)
Re: C and LL (1) loewis@informatik.hu-berlin.de (Martin von Loewis) (2001-10-27)
Re: C and LL (1) andrew@blueoffice.com (Andrew Wilson) (2001-10-27)
Re: C and LL (1) frigot_e@epita.fr (2001-10-27)
Re: C and LL (1) loewis@informatik.hu-berlin.de (Martin von Loewis) (2001-10-28)
Re: C and LL (1) dr_feriozi@prodigy.net (2001-11-04)
Re: C and LL (1) GOLDParser@DevinCook.com (2001-11-05)
Re: C and LL (1) gzw@home.com (Geoff Wozniak) (2001-11-08)
Re: C and LL (1) joachim_d@gmx.de (Joachim Durchholz) (2001-11-11)
| List of all articles for this month |

From: dr_feriozi@prodigy.net
Newsgroups: comp.compilers
Date: 4 Nov 2001 23:52:47 -0500
Organization: Prodigy Internet http://www.prodigy.com
References: 01-10-121 01-10-134
Keywords: parse
Posted-Date: 04 Nov 2001 23:52:47 EST

frigot eric wrote:
> For exemple, just look at the if statement definition :
> if (expression) statement
> OR
> if (expression) statement else statement
> I don't think you can parse that with LL(1) grammar.
> You need to know if you've got the 'else' before reducing the if
> statement.


This can be LL(1) with great pain and awkwardness directly in the
grammar, as was done in an early Java grammar. Much easier is to just
use the "else" production as a resolution. This associates an else with
the closest if, as was intended. From the SLK output you get the
following resolution:


conflict at lookahead level 1
full conflict string: else


157: more_if --> else statement
following symbols:
                                        statement


158: more_if -->
following symbols:
                                        statement


Conflict 8 is ambiguous, using the first production (157).


Post a followup to this message

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