Simple Statements

A simple statement is an expression evaluated for its side effects. Every simple statement must end in a semicolon, unless it is the final statement in a block. In this case, the semicolon is optional (but strongly encouraged in any multiline block, since you may eventually add another line).

Even though some operators (like eval {} and do {}) look like compound statements, they aren't. True, they allow multiple statements on the inside, but that doesn't count. From the outside those statements are just terms in an expression, and thus need an explicit semicolon if used as the last item in a statement.

Any simple statement may optionally be followed by a single modifier, just before the terminating semicolon (or block ending). The possible modifiers are:

if EXPR
unless EXPR
while EXPR
until EXPR

The if and unless modifiers work pretty much as you'd expect if you speak English:

$trash->take('out') if $you_love_me;
shutup() unless $you_want_me_to_leave;

The while and until modifiers evaluate repeatedly as long as the modifier is true:

$expression++ while -e "$file$expression";
kiss('me') until $I_die;

The while and until modifiers also have the usual while-loop semantics (conditional evaluated first), except when applied to a do {} (or to the now-deprecated do-SUBROUTINE statement), in which case the block executes once before the conditional is evaluated. This is so that you can write loops like:

do {
    $line = <STDIN>;
    ...
} until $line eq ".\n";

See the do entry in Chapter 3, Functions. Note also that the loop-control statements described later will not work in this construct, since modifiers don't take loop labels. Sorry. You can always wrap another block around it to do that sort of thing. Or write a real loop with multiple loop-control commands inside. Speaking of real loops, we'll talk about compound statements next.

Compound Statements

A sequence of statements that defines a scope is called a block. Sometimes a block is delimited by the file containing it (in the case of either a "required" file, or the program as a whole), and sometimes it's delimited by the extent of a string (in the case of an eval). But generally, a block is delimited by braces ({}). When we mean a block with braces, we'll use the term BLOCK.

Compound statements are built out of expressions and BLOCKs. The expressions are built out of the terms and operators we've already discussed. In our syntax diagrams, we'll use the word EXPR to indicate a place where you can use an expression.

The following conditionals and loops may be used to control flow:

if (EXPR) BLOCK
if (EXPR) BLOCK else BLOCK
if (EXPR) BLOCK elsif (EXPR) BLOCK ...
if (EXPR) BLOCK elsif (EXPR) BLOCK ... else BLOCK
LABEL while (EXPR) BLOCK
LABEL while (EXPR) BLOCK continue BLOCK
LABEL for (EXPR; EXPR; EXPR) BLOCK
LABEL foreach VAR (LIST) BLOCK
LABEL foreach VAR (LIST) BLOCK continue BLOCK
LABEL BLOCK
LABEL BLOCK continue BLOCK

Note that unlike in C and Pascal, these are defined in terms of BLOCKs, not statements. This means that the braces are required--no dangling statements allowed. If you want to write conditionals without braces there are several other ways to do it. The following all do the same thing:

if (!open(FOO, $foo)) { die "Can't open $foo: $!"; }
 
die "Can't open $foo: $!" unless open(FOO, $foo);
open(FOO, $foo) or die "Can't open $foo: $!";     # FOO or bust!
open(FOO, $foo) ? 'hi mom' : die "Can't open $foo: $!";
                    # a bit exotic, that last one

Your authors would tend to prefer the third of those under most circumstances.

If Statements

The if statement is straightforward. Since BLOCKs are always bounded by braces, there is never any ambiguity about which if an else or an elsif goes with. In any particular sequence of if/elsif/else BLOCKs, only the first one that has a true condition will be executed. If none of them is true, then the else BLOCK, if there is any, is executed.

If you use unless in place of if, the sense of the test is reversed. That is:

unless ($OS_ERROR) ...

is equivalent to:[38]

[38] $OS_ERROR is the same as $! if you use English.

if (not $OS_ERROR) ...

Loop Statements

All compound loop statements have an optional LABEL. If present, the label consists of an identifier followed by a colon. It's customary to make the label upper case to avoid potential conflict with reserved words, and so it stands out better. (But don't use BEGIN or END!)

for ($i = 1; $i < 10; $i++) {
    ...
}

$i = 1;
while ($i < 10) {
    ...
}
continue {
    $i++;
}

for ($i = 0, $bit = 1; $mask & $bit; $i++, $bit << 1) {
    print "Bit $i is set\n";
}

$on_a_tty = -t STDIN && -t STDOUT;
sub prompt { print "yes? " if $on_a_tty }
for ( prompt(); <STDIN>; prompt() ) {
    # do something
}

for (;;) {
    ...
}

foreach VAR (LIST) {
    ...
}

for (@ary) { s/ham/turkey/ }                # substitution
foreach $elem (@elements) {                 # multiply by 2
    $elem *= 2;
}
for $count (10,9,8,7,6,5,4,3,2,1,'BOOM') {  # do a countdown
    print $count, "\n"; sleep(1);
}
for $count (reverse 'BOOM', 1..10) {        # same thing
    print $count, "\n"; sleep(1);
}
for $item (split /:[\\\n:]*/, $TERMCAP) {   # any LIST expression
    print "Item: $item\n";
}
foreach $key (sort keys %hash) {            # sorting keys
    print "$key => $hash{$key}\n";
}

for ($i = 0; $i < @ary1; $i++) {
    for ($j = 0; $j < @ary2; $j++) {
        if ($ary1[$i] > $ary2[$j]) {
            last; # can't go to outer :-(
        }
        $ary1[$i] += $ary2[$j];
    }
    # this is where that last takes me
}

WID: foreach $this (@ary1) { 
    JET: foreach $that (@ary2) {
        next WID if $this > $that;
        $this += $that;
    } 
}

next LINE if /^#/;      # discard comments

last LABEL
next LABEL
redo LABEL

LINE: while (<STDIN>) {
    last LINE if /^$/;      # exit when done with header
    ...
}

LINE: while (<STDIN>) {
    next LINE if /^#/;      # skip comments
    next LINE if /^$/;      # skip blank lines
    ...
} continue {
    $count++;
}

while (<>) {
    chomp;
    if (s/\\$//) { 
        $_ .= <>; 
        redo;
    }
    # now process $_
}

LINE: while ($line = <ARGV>) {
    chomp($line);
    if ($line =~ s/\\$//) { 
        $line .= <ARGV>; 
        redo LINE;
    }
    # now process $line
}

open FILE, $file
     or warn "Can't open $file: $!\n", next FILE;   # WRONG

open FILE, $file
     or warn("Can't open $file: $!\n"), next FILE;   # okay

Bare Blocks and Case Structures

A BLOCK by itself (labeled or not) is semantically equivalent to a loop that executes once. Thus you can use last to leave the block or redo to restart the block.[41] Note that this is not true of the blocks in eval {}, sub {}, or do {} commands, which are not loop blocks and cannot be labeled. They can't be labeled because they're just terms in an expression. Loop control commands may only be used on true loops, just as the return command may only be used within a subroutine or eval. But you can always introduce an extra set of braces to give yourself a bare block, which counts as a loop.

[41] For reasons that may (or may not) become clear upon reflection, a next also exits the once-through block. There is a slight difference, however, in that a next will execute a continue block, while a last won't.

The bare block is particularly nice for doing case structures (multiway switches).

SWITCH: {
    if (/^abc/) { $abc = 1; last SWITCH; }
    if (/^def/) { $def = 1; last SWITCH; }
    if (/^xyz/) { $xyz = 1; last SWITCH; }
    $nothing = 1;
}

There is no official switch statement in Perl, because there are already several ways to write the equivalent. In addition to the above, you could write: [42]

[42] This code is actually not as strange as it looks once you realize that you can use loop-control operators within an expression. That's just the normal scalar (C-style) comma operator between the assignment and the last. It evaluates the assignment for its side-effect, and then exits the loop in question, which happens to be a bare block named SWITCH.

SWITCH: {
    $abc = 1, last SWITCH  if /^abc/;
    $def = 1, last SWITCH  if /^def/;
    $xyz = 1, last SWITCH  if /^xyz/;
    $nothing = 1;
}

or:

SWITCH: {
    /^abc/ && do { $abc = 1; last SWITCH; };
    /^def/ && do { $def = 1; last SWITCH; };
    /^xyz/ && do { $xyz = 1; last SWITCH; };
    $nothing = 1;
}

or, formatted so it stands out more as a "proper" switch statement:

SWITCH: {
    /^abc/      && do { 
                        $abc = 1; 
                        last SWITCH; 
                   };
    /^def/      && do { 
                        $def = 1; 
                        last SWITCH; 
                   };
    /^xyz/      && do { 
                        $xyz = 1; 
                        last SWITCH; 
                    };
    $nothing = 1;
}

or:

SWITCH: {
    /^abc/      and $abc = 1, last SWITCH;
    /^def/      and $def = 1, last SWITCH;
    /^xyz/      and $xyz = 1, last SWITCH;
    $nothing = 1;
}

or even, horrors:

if    (/^abc/) { $abc = 1 }
elsif (/^def/) { $def = 1 }
elsif (/^xyz/) { $xyz = 1 }
else           { $nothing = 1 }

You might think it odd to write a loop over a single value, but a common idiom for a switch statement is to use foreach's aliasing capability to make a temporary assignment to $_ for convenient matching:

for ($some_ridiculously_long_variable_name) {
    /In Card Names/     and do { push @flags, '-e'; last; };
    /Anywhere/          and do { push @flags, '-h'; last; };
    /In Rulings/        and do {                    last; };
    die "unknown value for form variable where: `$where'";
}

Notice how the last commands in that example ignore the do {} blocks, which aren't loops, and exit the main loop instead.

Goto

Although not for the faint of heart (or the pure of heart, for that matter), Perl does support a goto command. There are three forms: goto LABEL, goto EXPR, and goto &NAME.

The goto LABEL form finds the statement labeled with LABEL and resumes execution there. It may not be used to go inside any construct that requires initialization, such as a subroutine or a foreach loop. It also can't be used to go into a construct that is optimized away. It can be used to go almost anywhere else within the current block or one you were called from, including out of subroutines, but it's usually better to use some other construct. The author of Perl has never felt the need to use this form of goto (in Perl, that is--C is another matter).

The goto EXPR form is just a generalization of goto LABEL. It expects the expression to return a label name, whose location obviously has to be resolved dynamically by the interpreter. (Don't expect this to work in compiled Perl.) This allows for computed gotos per FORTRAN, but isn't necessarily recommended if you're optimizing for maintainability:

goto ("FOO", "BAR", "GLARCH")[$i];

In almost all cases like this, it's usually a far, far better idea to use the structured control flow mechanisms of next, last, or redo instead of resorting to a goto. For certain applications, a hash of function pointers or the catch-and-throw pair of eval and die for exception processing can also be prudent approaches.

The goto &NAME form is highly magical, and quite different from an ordinary goto. It substitutes a call to the named subroutine for the currently running subroutine. This is used by AUTOLOAD subroutines that wish to load another subroutine and then pretend that the other subroutine had been called in the first place. After the goto, not even caller will be able to tell that this routine was called first. See Chapter 3, Functions for a discussion of caller and Chapter 7, The Standard Perl Library for AutoLoader.

Global Declarations

Subroutine and format declarations are global declarations. No matter where you place them, they declare global thingies (actually, package thingies, but packages are global) that are visible from everywhere. Global declarations can be put anywhere a statement can, but have no effect on the execution of the primary sequence of statements--the declarations take effect at compile time. Typically the declarations are put at the beginning or the end of your program, or off in some other file. However, if you're using lexically scoped private variables created with my, you'll want to make sure your format or subroutine definition is within the same block scope as the my if you expect to be able to access those private variables.[43]

[43] For esoteric reasons related to closures, lexicals, and the foreach aliasing mechanism, these my variables must not be the index variable of a foreach loop, because any named subroutine or format will only have been compiled with the first binding.

Formats are bound to a filehandle and accessed implicitly via the write function. For more on formats, see "Formats" later in this chapter.

Subroutines are generally accessed directly, but don't actually have to be defined before calls to them can be compiled. The difference between a subroutine definition and a mere declaration is that the definition supplies a BLOCK containing the code to be executed, while the declaration doesn't. A subroutine definition can function as a declaration if the subroutine hasn't previously been declared.

Declaring a subroutine allows a subroutine name to be used as if it were a list operator from that point forward in the compilation. You can declare a subroutine without defining it by just saying:

sub myname;
$me = myname $0             or die "can't get myname";

Note that it functions as a list operator, though, not as a unary operator, so be careful to use or instead of ||. The || binds too tightly to use after a list operator (at least, not without using extra parentheses to turn the list operator back into a function call).[44] You also need to define the subroutine at some point, or you'll get an error at run-time indicating that you've called an undefined subroutine.

[44] Alternately, turn the subroutine into a unary operator with a prototype. But we haven't talked about that yet.

Subroutine definitions can be loaded from other files with the require statement, but there are two problems with that. First, the other file will typically insert the subroutine names into a package (a namespace) of its own choosing, not your package. Second, a require happens at run-time, so the declaration occurs too late to serve as a declaration in the file invoking the require.

A more useful way to pull in declarations and definitions is via the use declaration, which essentially performs a require at compile time and then lets you import declarations into your own namespace. Because it is importing names into your own (global) package at compile time, this aspect of use can be considered a kind of global declaration. See Chapter 5, Packages, Modules, and Object Classes for details on this.

Scoped Declarations

Like global declarations, lexically scoped declarations have an effect at the time of compilation. Unlike global declarations, lexically scoped declarations have an effect only from the point of the declaration to the end of the innermost enclosing block. That's why we call them lexically scoped, though perhaps "textually scoped" would be more accurate, since lexical scoping has nothing to do with lexicons. But computer scientists the world around know what "lexically scoped" means, so we perpetuate the usage here.

We mentioned that some aspects of use could be considered global declarations, but there are other aspects that are lexically scoped. In particular, use is not only used to perform symbol importation but also to implement various magical pragmas (compiler hints). Most such pragmas are lexically scoped, including the use strict vars pragma that forces you to use lexically declared variables. See the section "Pragmas" below.

A package declaration, oddly enough, is lexically scoped, despite the fact that a package is a global entity. But a package declaration merely declares the identity of the default package for the rest of the enclosing block. Undeclared, unqualified variable names will be looked up in that package. In a sense, a package isn't declared at all, but springs into existence when you refer to a variable that belongs in the package. It's all very Perlish.

The most frequently seen form of lexically scoped declaration is the declaration of my variables. A related form of scoping known as dynamic scoping applies to local variables, which are really global variables in disguise. If you refer to a variable that has not been declared, its visibility is global by default, and its lifetime is forever. A variable used at one point in your program is accessible from anywhere else in the program.[45] If this were all there were to the matter, Perl programs would quickly become unwieldy as they grew in size. Fortunately, you can easily create private variables using my, and semi-private values of global variables using local. A my or a local declares the listed variables (in the case of my), or the values of the listed global variables (in the case of local), to be confined to the enclosing block, subroutine, eval, or file. If more than one variable is listed, the list must be placed in parentheses. All listed elements must be legal lvalues. (For my the constraints are even tighter: the elements must be simple scalar, array, or hash variables, and nothing else.) Here are some examples of declarations of lexically scoped variables:

[45] To reiterate, even apparently global variables aren't really global--they're actually package variables. These work a bit like C's file static variables, or C++'s class static variables. Packages are used by libraries, modules, and classes to store their own private data so it doesn't conflict with data in your main program. If you see someone write $Some::stuff or $Some'stuff, they're using the $stuff scalar variable from the package Some. See Chapter 5, Packages, Modules, and Object Classes.

my $name = "fred";
my @stuff = ("car", "house", "club");
my ($vehicle, $home, $tool) = @stuff;

(These declarations also happen to perform an initializing assignment at run-time.)

A local variable is dynamically scoped, whereas a my variable is lexically scoped. The difference is that any dynamic variables are also visible to functions called from within the block in which those variables are declared. Lexical variables are not. They are totally hidden from the outside world, including any called subroutines (even if it's the same subroutine called from itself or elsewhere--every instance of the subroutine gets its own copy of the variables).[46] In either event, the variable (or local value) disappears when the program exits the lexical scope in which the my or local finds itself. By and large, you should prefer to use my over local because it's faster and safer. But you have to use local if you want to temporarily change the value of an existing global variable, such as any of the special variables listed at the end of this chapter. Only alphanumeric identifiers may be lexically scoped. We won't talk much more about the semantics of local here. See local in Chapter 3, Functions for more information.

[46] An eval, however, can see the lexical variables of the scope it is being evaluated in, so long as the names aren't hidden by declarations within the eval itself. Likewise, any anonymous subroutine (closure) created within the scope will also see such lexical variables. See Chapter 4, References and Nested Data Structures for more on closures.

Syntactically, my and local are simply modifiers (adjectives) on an lvalue expression. When you assign to a modified lvalue, the modifier doesn't change whether the lvalue is viewed as a scalar or a list. To figure how the assignment will work, just pretend that the modifier isn't there. So:

my ($foo) = <STDIN>;
my @FOO = <STDIN>;

both supply a list context to the right-hand side, while:

my $foo = <STDIN>;

supplies a scalar context.

The my binds more tightly (with higher precedence) than the comma does. The following only declares one variable because the list following my is not enclosed in parentheses:

my $foo, $bar = 1;

This has the same effect as:

my $foo;
$bar = 1;

(You'll get a warning about the mistake if you use -w.)

The declared variable is not introduced (is not visible) until after the current statement. Thus:

my $x = $x;

can be used to initialize the new inner $x with the value of the old outer $x. (Not that we recommend this style.) On the other hand, the expression:

my $x = 123 and $x == 123

is false unless the old $x just happened to have the value 123.

Declaring a lexical variable of a particular name hides any previously declared lexical variable of the same name. It also hides any unqualified global variable of the same name, but you can always get to the global variable by explicitly qualifying it with the name of the package the global is in.

For example:

$PackageName::varname

A statement sequence may contain declarations of lexically scoped variables, but apart from declaring variable names, the declarations act like ordinary statements, and each of them is elaborated within the sequence of statements as if it were an ordinary statement.

Pragmas

Many languages allow you to give hints to the compiler. In Perl these hints are conveyed to the compiler with the use declaration. Some of the pragmas are:

use integer
use strict
use lib
use sigtrap
use subs
use vars

All the Perl pragmas are described in Chapter 7, The Standard Perl Library, but we'll talk about some of the more useful ones here.

By default, Perl assumes that it must do much of its arithmetic in floating point. But by saying:

use integer;

you may tell the compiler that it's okay to use integer operations from here to the end of the enclosing block. An inner block may countermand this by saying:

no integer;

which lasts until the end of that inner block.

Some users may wish to encourage the use of lexical variables. As an aid to catching implicit references to package variables, if you say:

use strict 'vars';

then any variable reference from there to the end of the enclosing block must either refer to a lexical variable, or must be fully qualified with the package name. A compilation error results otherwise. An inner block may countermand this with:

no strict 'vars'

You can also turn on strict checking of symbolic references and barewords with this pragma. Often people say use strict; to turn on all three strictures.

Subroutines and variables that are imported from other modules have special privileges in Perl. Imported subroutines can override many built-in operators, and imported variables are exempt from use strict 'vars', since importation is considered a form of declaration. Sometimes you want to confer these privileges on your own subroutines and variables. You can do this with:

use subs qw(&read &write);

and:

use vars qw($fee $fie $foe $foo @sic);

Finally, Perl searches for modules in a standard list of locations. You need to be able to add to that list at compile time, because when you use modules they're loaded at compile time, and adding to the list at run-time would be too late. So you can put:

use lib "/my/own/lib/directory";

at the front of your program to do this. Note that these last three pragmas all modify global structures, and can therefore have effects outside of the current lexical scope.