views:

413

answers:

8

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 either referred to the syntax documentation that says that braces are required, which I think is just begging the question, or ignored the question and simply gave braceless alternatives.

Why does Perl require braces for control statements like if and for? Put another way, why does Perl require blocks rather than statements, like some other popular languages allow?

+15  A: 

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

Jérémie Koenig
half of that particular one is easy - if $condition is independent of do_something then it applies to the while thing. it's not like you can tell what PERL means anyways tho
wowest
Speak for yourself. And perl's not an acronym.
Oesor
Drew Hall
It's not really an acronym. Those backronyms are just for fun; the name Perl itself comes from an intentional spelling deviation from Pearl.
ephemient
+12  A: 

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.

Adam Bellaire
"Preventing programmer mistakes" doesn't seem like a very "Perlish" reason, at least not for the time the syntax was established.
Rob Kennedy
@Rob: You're kidding, right? Larry was a C programmer. He'd probably seen this exact mistake more times than you or I would care to contemplate. Why wouldn't he decide to preclude it in a language he designed, and why would the time have anything to do with it?
Adam Bellaire
It seems to me like there are so many *other* places where it's easy to make a mistake in Perl; and *this* is the one Wall chose to address? As for the time, I feel like maintainability and beginner-frienliness are more highly valued than they were 20 years ago, so I find it a little hard to believe this would have been included with *those* as the goal. (Fortunate side effects, fine, but not the primary motivation.)
Rob Kennedy
@Rob: "Preventing programmer mistakes" is exactly the answer, though. Many of the things that seem a bit off from C were from Larry explicitly avoiding those problems from C coding. I don't have a reference from you because I'm mostly just heard it directly from Larry's mouth.
brian d foy
@Rob: I think your argument is going in the wrong direction, and that the modern, popular opinion of Perl is affecting your judgment. It's absurd to think that a person would come up with a language with no regard to preventing mistakes. A couple decades later, it's more obvious in Perl mistakes are easy to make: *That* is an unfortunate side-effect.
Adam Bellaire
Brian's comment is exactly the sort of input I was hoping for. As I mentioned, this wasn't the answer I expected, but if he says this is the reason Wall had, then so be it. I don't need a reference; I'll take his word for it (although references are still welcome).
Rob Kennedy
A: 

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... :)

Drew Hall
I'm assuming the downvote is for that last little barb? :) Don't get me wrong, I actually love Perl--but its elaborate syntax can make the code "write only".
Drew Hall
It could also be because your answer's a guess, which is not an answer (but I can't tell as I'm not the author of it :))
Romain
The down-vote could have been for either or both of those reasons. The "just guessing" part was a turn-off for me. There was no information by which to judge whether it was right. Nothing wrong with guessing, but guessing *with evidence* is better.
Rob Kennedy
+5  A: 
ephemient
The Go language has this also.
Dan
+5  A: 

In Programming Perl (which Larry Wall co-authored), 3rd Edition, page 113, compound statements are defined in terms of expressions and blocks, not statements, and blocks have braces.

Note that unlike in C and Java, [compound statements] are defined in terms of BLOCKS, not statements. This means that the braces are requried--no dangling statements allowed.

I don't know if that answers your question but it seems like in this case he chose to favor a simple language structure instead of making exceptions.

Phil
It would also support (though not prove) the notion that he wanted to preclude the errors mentioned by Drew Hall and I in our answers...
Adam Bellaire
"--no dangling statements allowed" seems like an affirmation of the answer provided in a comment by Brian above.
Leonardo Herrera
+7  A: 

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.

araqnid
I seem to remember Larry pointing out this case in one of his presentations in an answer to the same question.
brian d foy
+2  A: 

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

Svante
The quotation marks and the italics suggest you're quoting someone. Could you cite your source, please?
Rob Kennedy
The source is my evil voice ;) -- I just wanted to let the rant stand out as such.
Svante
+4  A: 

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);
el.pescado
Kinda surprised nobody else brought this up. Yes, "statement modifiers" are Perl's answer to the blockless condition. They allow one to write conditions in a single line and to put the thing you're doing first, because sometimes its more important to emphasize what is being done over when or how many times.
Schwern
Except that this doesn't *completely* cover the functionality of C-style blockless `if`, in that postfix conditionals don't provide a way to include an `else` clause.
Dave Sherohman
Schwern, I suspect nobody else brought it up because in my question I said I wasn't satisfied by answers that merely listed braceless alternatives. (For that, go to the other question.) I wanted to know why the regular control statements couldn't be braceless. If the statement modifiers really *were* the reason for requiring braces elsewhere, then that's fine, but some historical evidence would have been nice. Besides, this answer doesn't actually say that; it *asks* that.
Rob Kennedy