home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam

# Chapter 3. Unary and Binary Operators

In the last chapter, we talked about the various kinds of terms you might use in an expression, but to be honest, isolated terms are a bit boring. Many terms are party animals. They like to have relationships with each other. The typical young term feels strong urges to identify with and influence other terms in various ways, but there are many different kinds of social interaction and many different levels of commitment. In Perl, these relationships are expressed using operators.

Sociology has to be good for something.

From a mathematical perspective, operators are just ordinary functions with special syntax. From a linguistic perspective, operators are just irregular verbs. But as any linguist will tell you, the irregular verbs in a language tend to be the ones you use most often. And that's important from an information theory perspective because the irregular verbs tend to be shorter and more efficient in both production and recognition.

In practical terms, operators are handy.

Operators come in various flavors, depending on their arity (how many operands they take), their precedence (how hard they try to take those operands away from surrounding operators), and their associativity (whether they prefer to do things right to left or left to right when associated with operators of the same precedence).

Perl operators come in three arities: unary, binary, and trinary (or ternary, if your native tongue is Shibboleth). Unary operators are always prefix operators (except for the postincrement and postdecrement operators).[1] The others are all infix operators--unless you count the list operators, which can prefix any number of arguments. But most people just think of list operators as normal functions that you can forget to put parentheses around. Here are some examples:

```! \$x                # a unary operator
\$x * \$y             # a binary operator
\$x ? \$y : \$z        # a trinary operator
print \$x, \$y, \$z    # a list operator```
An operator's precedence controls how tightly it binds. Operators with higher precedence grab the arguments around them before operators with lower precedence. The archetypal example is straight out of elementary math, where multiplication takes precedence over addition:
`2 + 3 * 4          # yields 14, not 20`
The order in which two operators of the same precedence are executed depends on their associativity. These rules also follow math conventions to some extent:
```2 * 3 * 4          # means (2 * 3) * 4, left associative
2 ** 3 ** 4        # means 2 ** (3 ** 4), right associative
2 != 3 != 4        # illegal, nonassociative```
Table 3-1 lists the associativity and arity of the Perl operators from highest precedence to lowest.

[1]Though you can think of various quotes and brackets as circumfix operators that delimit terms.

#### Table 3.1. Operator Precedence

Associativity Arity Precedence Class
None 0 Terms, and list operators (leftward)
Left 2 ->
None 1 ++ --
Right 2 **
Right 1 ! ~ > and unary + and -
Left 2 =~ !~
Left 2 * / % x
Left 2 + - .
Left 2 << >>
Right 0,1 Named unary operators
None 2 < > <= >= lt gt le ge
None 2 == != <=> eq ne cmp
Left 2 &
Left 2 | ^
Left 2 &&
Left 2 ||
None 2 .. ...
Right 3 ?:
Right 2 = += -= *= and so on
Left 2 , =>
Right 0+ List operators (rightward)
Right 1 not
Left 2 and
Left 2 or xor

It may seem to you that there are too many precedence levels to remember. Well, you're right, there are. Fortunately, you've got two things going for you here. First, the precedence levels as they're defined usually follow your intuition, presuming you're not psychotic. And second, if you're merely neurotic, you can always put in extra parentheses to relieve your anxiety.

Another helpful hint is that any operators borrowed from C keep the same precedence relationship with each other, even where C's precedence is slightly screwy. (This makes learning Perl easier for C folks and C++ folks. Maybe even Java folks.)

The following sections cover these operators in precedence order. With very few exceptions, these all operate on scalar values only, not list values. We'll mention the exceptions as they come up.

Although references are scalar values, using most of these operators on references doesn't make much sense, because the numeric value of a reference is only meaningful to the internals of Perl. Nevertheless, if a reference points to an object of a class that allows overloading, you can call these operators on such objects, and if the class has defined an overloading for that particular operator, it will define how the object is to be treated under that operator. This is how complex numbers are implemented in Perl, for instance. For more on overloading, see Chapter 13, "Overloading".

## 3.1. Terms and List Operators (Leftward)

Any term is of highest precedence in Perl. Terms include variables, quote and quotelike operators, most expressions in parentheses, or brackets or braces, and any function whose arguments are parenthesized. Actually, there aren't really any functions in this sense, just list operators and unary operators behaving as functions because you put parentheses around their arguments. Nevertheless, the name of Chapter 29 is Functions.

Now listen carefully. Here are a couple of rules that are very important and simplify things greatly, but may occasionally produce counterintuitive results for the unwary. If any list operator (such as print) or any named unary operator (such as chdir) is followed by a left parenthesis as the next token (ignoring whitespace), the operator and its parenthesized arguments are given highest precedence, as if it were a normal function call. The rule is this: If it looks like a function call, it is a function call. You can make it look like a nonfunction by prefixing the parentheses with a unary plus, which does absolutely nothing, semantically speaking--it doesn't even coerce the argument to be numeric.

For example, since || has lower precedence than chdir, we get:

```chdir \$foo    || die;       # (chdir \$foo) || die
chdir(\$foo)   || die;       # (chdir \$foo) || die
chdir (\$foo)  || die;       # (chdir \$foo) || die
chdir +(\$foo) || die;       # (chdir \$foo) || die```
but, because * has higher precedence than chdir, we get:
```chdir \$foo * 20;            # chdir (\$foo * 20)
chdir(\$foo) * 20;           # (chdir \$foo) * 20
chdir (\$foo) * 20;          # (chdir \$foo) * 20
chdir +(\$foo) * 20;         # chdir (\$foo * 20)```
Likewise for any numeric operator that happens to be a named unary operator, such as rand:
```rand 10 * 20;               # rand (10 * 20)
rand(10) * 20;              # (rand 10) * 20
rand (10) * 20;             # (rand 10) * 20
rand +(10) * 20;            # rand (10 * 20)```
In the absence of parentheses, the precedence of list operators such as print, sort, or chmod is either very high or very low depending on whether you look at the left side or the right side of the operator. (That's what the "Leftward" is doing in the title of this section.) For example, in:
```@ary = (1, 3, sort 4, 2);
print @ary;         # prints 1324```
the commas on the right of the sort are evaluated before the sort, but the commas on the left are evaluated after. In other words, a list operator tends to gobble up all the arguments that follow it, and then act like a simple term with regard to the preceding expression. You still have to be careful with parentheses:
```# These evaluate exit before doing the print:
print(\$foo, exit);  # Obviously not what you want.
print \$foo, exit;   # Nor this.

# These do the print before evaluating exit:
(print \$foo), exit; # This is what you want.
print(\$foo), exit;  # Or this.
print (\$foo), exit; # Or even this.```
The easiest place to get burned is where you're using parentheses to group mathematical arguments, and you forget that parentheses are also used to group function arguments:
`print (\$foo & 255) + 1, "\n";   # prints (\$foo & 255)`
That probably doesn't do what you expect at first glance. Fortunately, mistakes of this nature generally produce warnings like "Useless use of addition in a void context" when warnings are enabled.

Also parsed as terms are the do {} and eval {} constructs, as well as subroutine and method calls, the anonymous array and hash composers [] and {}, and the anonymous subroutine composer sub {}.