Talk:Dangling else

Latest comment: 1 year ago by 107.197.56.204 in topic Practical programming

Ambiguity

edit

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.Reply

 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)Reply

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)Reply
"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)Reply
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)Reply
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)Reply
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)Reply
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)Reply

Nonsense about Modula-2 removed.

edit

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)Reply

Grammar disallowing ambiguous if

edit

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

Practical programming

edit

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)Reply