0

I believe everyone who reads it is familiar with the dangling else ambiguity. Therefore I will skip the explanation. I found on a compilers book(the dragon book) a not ambiguous grammar that represents IF and ELSE. Here it is.

stmt->matched_stmt | open_stmt
matched_stmt->if exp then matched_stmt else matched_stmt | other
open_stmt->if exp then stmt | if exp then matched_stmt else open_stmt

The problems is:

open_stmt->if exp then stmt | if exp then matched_stmt else open_stmt

In order to make the grammar I am work on a LL(1) grammar, I need to eliminate left common prefix, and in this case the left common prefix is:

if exp then

when I try to factory it then it again become ambiguous, this is what I tried.

stmt->matched_stmt | open_stmt
matched_stmt->if exp then matched_stmt else matched_stmt | other
open_stmt->if exp thenO'
O'->stmt | matched_stmt else open_stmt

Which is ambiguous, can anyone help me make it not ambigous and with no common left prefix? thank you very much

Bruno Braga
  • 570
  • 2
  • 4
  • 13

1 Answers1

2

I don't believe it is possible to write an LL(1) grammar which will handle dangling else, although it is trivial to write a recursive descent parser which does so.

In the recursive descent parser, when you've done parsing the first statement after the expression, if you see an else you continue with the production. Otherwise, you've finished parsing the if statement. In other words, you simply parse the else clauses greedily.

But that algorithm cannot be expressed as a CFG, and I've always assumed that it is impossible to write an unambiguous LL(1) CFG which handles dangling elses, because when you reach the beginning of S1 in

if E then S1 ...

you still don't know which production that is part of. In fact, you don't know until you reach the end of S1, which is certainly well too late to make an LL(k) decision, no matter how big k is.

However, that explanation has a lot of hand-waving, and I've never found it completely satisfying. So I was gratified to pick up my battered copy of the Dragon book (1986 edition) and read, on page 192 ("LL(1) grammars" in section 4.4, "Top-down grammars") that grammar 4.13 (the if-then-optional-else grammar) "has no LL(1) grammar at all".

The following paragraph ends with sound advice: "if an LR parser generator… is available, one can get all of the benefits of predictive parsing and operator precedence automatically." My marginal note (from about 1986, I guess) reads "So why did I just study this whole chapter????"; today, I'd be inclined to be more generous with the authors of the Dragon book but not to the point of suggesting that anyone actually use a parser generator which is not at least as powerful as an LALR(1) parser generator.

rici
  • 234,347
  • 28
  • 237
  • 341
  • It is strange to think that a grammar that must handle if's and else's cannot be LL(1). I tried many things, but eveytime my parse table gets ambiguous (two different productions going to the same no terminal value). I guess that is it then, thank you very much. – Bruno Braga Sep 30 '15 at 15:53
  • @BrunoBraga Why must it be LL(1)? LL(1) is a very restrictive set of grammars; there are many constructs which cannot be adequately expressed in LL(1). A simple left-associative expression grammar cannot be correctly written in LL(1); you need to readjust the resulting right-associative parse tree to get the correct associativity. In practice, the if-else ambiguity is not serious because (as I mentioned) a recursive descent parser can easily make the correct decision and thus avoid the ambiguity, and most LL parser generators will handle that correctly. But personally, I go for LR parsing. – rici Sep 30 '15 at 17:25
  • No reason, I was just wondering if this is possible or not, since I am studying LL(1) grammars at the moment. – Bruno Braga Sep 30 '15 at 18:44