Re: Dangling else (Hans Aberg)
19 Feb 2006 11:05:34 -0500

          From comp.compilers

Related articles
Dangling else (borneq) (2006-02-19)
Re: Dangling else (2006-02-19)
Re: Dangling else (SM Ryan) (2006-02-24)
Re: Dangling else (Russ Cox) (2006-02-24)
Re: Dangling else (Russ Cox) (2006-02-24)
Re: Dangling else (SM Ryan) (2006-03-05)
Re: Dangling else (SM Ryan) (2006-03-05)
Re: Dangling else (=?ISO-8859-1?Q?Jan_Vorbr=FCggen?=) (2006-03-05)
[11 later articles]
| List of all articles for this month |

From: (Hans Aberg)
Newsgroups: comp.compilers
Date: 19 Feb 2006 11:05:34 -0500
Organization: Mathematics
References: 06-02-136
Keywords: parse
Posted-Date: 19 Feb 2006 11:05:34 EST

"borneq" <> wrote:

> I have grammar:
> S->ibtSeS
> S->ibtS
> S->s
> where i mean 'if', t:'then', e:'else'
> b:boolean expression, S - general statement, s - statement without
> "if..then,if..then..else"

> how resolve conflict depends on operator precedence and left/right
> association?

It depends on the method used to resolve precedence. Bison uses LARL(1)
token precedence, which merely looks at the tokens immediately before and
after the parsing "." in the conflicting rules (see the '.output' file
that can be generated). This method is not a grammar invariant, but
depends on the parsing algorithm. If the shift/reduce conflict is not
resolved, shift is chosen as default, which is the expected behavior in
the case of dangling 'else'. One can then choose to ignore the conflict,
using %expect. Alternatively, one merely sets precedence between the
conflicting tokens, which I recall are 'then' and 'else'. Associativity
does not make any difference, as that applies only to tokens of the same

    Hans Aberg

Post a followup to this message

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