Why do Perl control statements require braces?

Question

This may look like the recent question that asked why Perl doesn\'t allow one-liners to be \"unblocked,\" but I found the answers to that question unsatisfactory because they ei

Answer 1

One reason could be that some styles dictate that you should always use braces with control structures, even for one liners, in order to avoid breaking them later, e.g.:

if (condition) 
   myObject.doSomething();
else 
   myObject.doSomethingElse();

Then someone adds something more to the first part:

if (condition)
   myObject.doSomething();
   myObject.doSomethingMore(); // Syntax error next line
else 
   myObject.doSomethingElse();

Or worse:

if (condition)
   myObject.doSomething();
else 
   myObject.doSomethingElse();
   myObject.doSomethingMore(); // Compiles, but not what you wanted.

In Perl, these kinds of mistakes are not possible, because not using braces with control structures is always a syntax error. In effect, a style decision has been enforced at the language syntax level.

Whether that is any part of the real reason, only Larry's moustache knows.

Answer 2

One problem with braceless if-else clauses is they can lead to syntactic ambiguity:

if (foo)
    if (bar)
       mumble;
    else
       tumble;

Given the above, under what condition is tumble executed? It could be interpreted as happening when !foo or foo && !bar. Adding braces clears up the ambiguity without dirtying the source too much. You could then go on to say that it's always a good idea to have the braces, so let's make the language require it and solve the endless C bickering over whether they should be used or not. Or, of course, you could address the problem by getting rid of the braces completely and using the indentation to indicate nesting. Both are ways of making clear, unambiguous code a natural thing rather than requiring special effort.

Answer 3

"Okay, so normally, you need braces around blocks, but not if the block is only one statement long, except, of course, if your statement would be ambiguous in a way that would be ruled by precedence rules not like you want if you omitted the braces -- in this case, you could also imagine the use of parentheses, but that would be inconsistent, because it is a block after all -- this is of course dependent on the respective precedence of the involved operators. In any case, you don't need to put semicolons after closing braces -- it is even wrong if you end an if statement that is followed by an else statement -- except that you absolutely must put a semicolon at the end of a header file in C++ (or was it C?)."

Seriously, I am glad for every explicitness and uniformity in code.

Answer 4

One reason could be that some constructs would be ambiguous without braces :

foreach (@l) do_something unless $condition;

Does unless $condition apply to the whole thing or just the do_something statement?

Of course this could have been worked out with priority rules or something, but it would have been yet another way to create confusing Perl code :-)

Answer 5

Isn't it that Perl allows you to skip the braces, but then you have to write statement before condition? i.e.

#!/usr/bin/perl

my $a = 1;

if ($a == 1) {
    print "one\n";
}

# is equivalent to:

print "one\n" if ($a == 1);

Answer 6

Just guessing here, but "unblocked" loops/ifs/etc. tend to be places where subtle bugs are introduced during code maintenance, since a sloppy maintainer might try to add another line "inside the loop" without realizing that it's not really inside.

Of course, this is Perl we're talking about, so probably any argument that relies on maintainability is suspect... :)