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