Talk:Dangling else

Ambiguity

I think someone should remove from the page the link to "mightyheave". It is just spam for a parser generator and provide no link related to "danglin else" problem. I can't remove that usless reference because i just see a "reflist" keywork.. Or in alternative if the author of that blog is still around should provide a code snippet for resolving the dangling else. (a simple descent parser is a good start for a beg). Darioloso (talk) 14:42, 29 March 2015 (UTC) C and languages with similar syntax use braces to clearly define the body of the statement.

 if(a) if(b) return 1; else return 2;
 return 0;

I do believe the above code is ambiguous. C resolves to have the else relate to the rightmost ifUser:Serprex 18:56, 30 November 2008 (UTC)

It's not ambiguous to the compiler , just ambiguous to some (most?) programmers. I think the statement "C and languages with similar syntax use braces to clearly define the body of the statement" is wrong, It should be "C programmers and coding standards who normally use braces to clearly define the body of the statement" Iccaldwell (talk) 00:10, 1 December 2008 (UTC)

"It's not ambiguous to the compiler , just ambiguous to some (most?) programmers."

It's is ambiguous to the compiler. Grammars with this "dangling-else" are inherently ambiguous. The article talks about how different languages deal with the ambiguity. 75.45.110.58 (talk) 13:50, 5 January 2009 (UTC)

as User:Serprex says "C resolves to have the else relate to the rightmost if" so the compiler using extra rules can resolve it, so it is not ambiguous to the compiler. If may be ambiguous in terms of the grammar but a language is more that a grammar. and even if a language is ambiguous a given compiler might have extra rules so that it disambiguate an ambiguity in the language definition. Iccaldwell (talk) 22:50, 5 January 2009 (UTC)

This is descending into a philosophical argument about whether ambiguity exists if a compiler has rules to resolve the ambiguity. The grammar is ambiguous. End of story. Whether some particular compiler has some additional rule about how to resolve the ambiguity doesn't make the grammar less ambiguous.

If you don't believe that the dangling-else is ambiguous - which is the entire point of this article - then nominate this article for deletion, since the article would then be entirely wrong. 75.45.110.58 (talk) 23:04, 5 January 2009 (UTC)

I do believe dangling else is a problem for 'simple' grammars and programmers, but most real computer languages have rules that disambiguate it. Are those rule part of the grammar of the language: That's the philosophical argument. What I was trying to argue was that although its not technical ambiguous in C, it is for some/most programmers, so they always have to use braces.Iccaldwell (talk) 20:40, 6 January 2009 (UTC)

The dangling-else is ambiguous, but once a convention is fixed, as "attach to the closest if", you may write an unambiguous grammar.--132.204.242.63 (talk) 22:05, 23 November 2011 (UTC)

Nonsense about Modula-2 removed.

I have removed some absolute crap nonsense about Modula-2. Modula-2 uses "fully bracketed" if statements just like Ada, Algol68 and numerous other programming languages. As it stood, it would seem that a Modula-2 if statement would look like "IF c THEN s END ELSE s END", which is rubbish. How such an error could stay in for so long, makes me wonder... --Lasse Hillerøe Petersen (talk) 18:34, 13 February 2022 (UTC)

Grammar disallowing ambiguous if

In the article, there is a grammar that claims to forbid ambiguous if statements.

However, doesn't it allow the following?:

open_statement -> if(a) open_statement -> if(a) if(b) closed_statement else open_statement -> if(a) if(b) c else if(d) e

That could be parsed (if not by that grammar) as one of

• if(a) {if(b) c else {if(d) e}}
• if(a) {if(b) c} else {if(d) e} 2A00:6020:460B:9000:A12A:879B:6B7B:E243 (talk) 19:43, 25 July 2022 (UTC)

Practical programming

The second part of dangling else is omitted and needs to be added. A dangling else also includes the programmer's intention in the code to acknowledge that both the IF part and ELSE conditions were though of and handled.

A C like language example.

 if (x > 5)
 {
   x = x + 10;
 }
 else
 {
   //nothing to do
 }

It shows the programmer's intent.

A similar case with case/switch statements where the default case has an empty code block with a "//nothing to do" comment. For C++, there is the catch block with a "//nothing to do" comment signifying that the catch should do nothing. 107.197.56.204 (talk) 16:16, 18 January 2023 (UTC)