Statements, Semicolons and Blocks

Part I · Module 1 · Chapter 1.8 · Statements, Semicolons and Blocks

1. What One Statement Is

A statement is one complete instruction. Each of these is a statement:

use strict;
use warnings;
print "check starting\n";

Perl reads a file as a sequence of statements, works out what each one means while compiling, and then carries them out in order — the model from Chapter 1.5.

What makes this worth a chapter is that a statement is not the same thing as a line. Line breaks are whitespace to Perl. The boundary between statements is the semicolon, and nothing else.

2. The Semicolon Terminates

Two statements can share a line, and Perl is entirely content:

use strict;
use warnings;

print "first\n"; print "second\n";

first
second

One statement can also spread across several lines, because Perl keeps reading until it finds the semicolon. That is why a long instruction can be laid out for readability without any continuation marker — unlike a shell, where a line break ends the command unless you escape it.

Now the consequence that explains an error you have already seen. The semicolon is a terminator: it marks the end of a statement. It is not a separator between them. So when you leave one out, Perl does not stop at the line break and complain — it keeps reading, pulls the next line into the unfinished statement, and only objects when the combination makes no sense:

use strict;
use warnings;

print "first\n"
print "second\n";

syntax error at missing-semicolon.pl line 5, near "print"
Execution of missing-semicolon.pl aborted due to compilation errors.

The message names line 5; the missing semicolon is on line 4. That is not Perl being unhelpful — it genuinely had no reason to object until it reached the second print. Chapter 1.12 makes a habit of this; for now, note that the semicolon's job as a terminator is precisely why the report lands one line late.

3. Indentation Is for You, Not for Perl

Perl ignores leading whitespace entirely. These two programs are identical as far as the language is concerned:

print "a\n";
    print "b\n";
        print "c\n";

If you have come from Python, this is a real difference worth stating plainly: in Python indentation is the structure, and getting it wrong changes what the program does. In Perl, indentation carries no meaning at all — it is a message to the next human to read the file.

That does not make it optional in practice. Code that is indented inconsistently is read incorrectly by people, which is a slower and more expensive failure than a syntax error. Perl's position is simply that this is your problem and not its own.

4. Braces Group Statements Into a Block

Curly braces turn a group of statements into a single unit called a block. A block can stand on its own:

use strict;
use warnings;

print "before the block\n";
{
    my $inside = "visible only here";
    print "$inside\n";
}
print "after the block\n";

before the block
visible only here
after the block

A block on its own like this is unusual in real code — blocks normally belong to an if or a loop, which arrive in Modules 8 and 9. It is used here deliberately, because it isolates the one property of blocks that matters right now.

5. A Block Bounds a Variable's Life

my $inside declares the variable inside the block. When the block ends, the name is gone. Try to use it afterwards and the program does not even compile:

use strict;
use warnings;

{
    my $inside = 1;
}
print "$inside\n";

Global symbol "$inside" requires explicit package name (did you forget to declare "my $inside"?) at out-of-scope.pl line 7.
Execution of out-of-scope.pl aborted due to compilation errors.

Three things to take from that message:

• It is a compile error. Per Chapter 1.5, nothing ran — no output at all, not even from a print above it. Perl worked this out by reading the file, without executing anything.
• The region in which a name exists is called its scope. my creates a name whose scope runs from its declaration to the end of the enclosing block. Chapter 2.3 covers this properly.
• The message is about use strict. Without that pragma, the same program behaves completely differently — which is the subject of Chapter 1.10, and the reason that chapter immediately follows this one.

This is why blocks matter before you have met if or a loop: a block is the thing that decides how long a variable lives, and that turns out to be the mechanism by which Perl can catch a typo in a variable name at all.

6. Mistakes and How They Look

A missing semicolon. The error names the following line, as in §2. Always read the line above the one reported.

An unclosed brace. Perl reads to the end of the file looking for the match and then reports two messages:

Missing right curly or square bracket at unclosed.pl line 3, at end of line
syntax error at unclosed.pl line 3, at EOF

EOF means end of file. When you see it, the fault is almost never on the line reported — that is simply where the file ran out. Count your braces instead, which is what an editor's bracket matching is for.

Trusting the indentation. Because Perl ignores it, badly indented code can look like it is inside a block when it is not. If behaviour contradicts the layout, believe the braces.

Using a variable after its block. As in §5. The message mentions Global symbol and a package name, which sounds unrelated to scope until you have seen it once.

7. Why This Matters in Engineering Work

A short point, but a real one. Legacy flow scripts are frequently long, and the most common structural defect in them is not a wrong algorithm — it is a variable whose scope is wider than the author intended, so that one part of the script quietly reads a value another part left behind.

Understanding that a block bounds a name's life is what lets you read such a script and ask the right question: where is this value set, and is it still what I think it is by the time it is used? The habit of declaring a variable in the smallest block that needs it is the main defence, and it starts with knowing what a block is.

8. What You Should Be Able to Say Now

1. A statement is one instruction and ends at its semicolon; line breaks are just whitespace.
2. The semicolon is a terminator, which is why omitting one produces an error on the following line.
3. Perl ignores indentation entirely — it is for readers, and the braces are the structure.
4. Braces group statements into a block, which can stand alone.
5. A my variable exists from its declaration to the end of its enclosing block; using it later is a compile error under use strict.
6. Missing right curly ... at EOF means a brace was never closed, and the reported line is only where the file ended.

9. Exercise

Exercise 1 — statements are not lines. Write a script that prints three lines using only one physical line of code, then another that prints one line using a statement spread over three physical lines. Confirm both work.

Exercise 2 — locate the real fault. Take a four-statement script and remove one semicolon from the middle. Run it, write down the line number Perl reports, and the line the fault is actually on. Explain the difference in one sentence.

Exercise 3 — scope, by prediction. Before running it, say what out-of-scope.pl from §5 will print. Then run it, and say what you would change to make it print 1.

Exercise 4 — believe the braces. Write a bare block containing one print, then indent a second print to the same depth but place it after the closing brace. Predict which prints run when, then check. Say what this tells you about trusting layout.

10. Summary

• A statement ends at its semicolon, not at a line break; several can share a line and one can span many.
• The semicolon terminates, which is exactly why a missing one is reported against the next line.
• Indentation means nothing to Perl and everything to the next reader.
• Braces make a block, and a block can stand on its own.
• A block bounds a my variable's life, so using the name afterwards is caught while compiling — the mechanism behind the next chapter.
• at EOF means an unclosed brace, and the reported line is where the file ran out rather than where the fault is.

You now know what the units of a Perl program are. Chapter 1.9 covers the one piece of a file Perl deliberately ignores — comments — and what they are actually for.